From: Jan Kiszka <jan.kiszka@web.de> To: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [uq/master patch 2/5] kvm: add logging count to slots Date: Sun, 25 Apr 2010 16:29:45 +0200 [thread overview] Message-ID: <4BD451D9.4090209@web.de> (raw) In-Reply-To: <4BD44F13.3070000@redhat.com> [-- Attachment #1: Type: text/plain, Size: 1459 bytes --] Avi Kivity wrote: > On 04/25/2010 04:57 PM, Jan Kiszka wrote: >> >>> It's still a good idea. The current API assumes that there will be only >>> one slot-based client (or that multiple clients will keep the refcount >>> themselves). >>> >>> After the bytemap -> multiple bitmaps conversion this can be >>> extended to >>> each client getting its own bitmap (and therefore, s/refcount/list of >>> bitmaps/ and s/!refcount/list_empty()/). >>> >>> >> No concerns if >> - there is an existing use case for multiple clients, at least in >> qemu-kvm >> > > There isn't. But I don't like hidden breakage. It's (so far) an unproblematic API property we can document. I don't like changing APIs just for "there might be the case that...". > >> - the logging API is consistently converted, not just extended >> (IOW, migration_log is converted to logging_count) >> > > migration_log needs to remain global, since we want hotplug memory to > autostart logging. Can't follow yet, what will be the usage pattern of kvm_set_migration_log? Or would the hotplug code require a separate interface? Is it already the multi-client use case I'm looking for? > >> - someone signs he checked that current use of start/stop in qemu is >> completely symmetrical (I think to remember this used to be not the >> case, but I might be wrong) >> > > I remember this too. Marcelo? > Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de> To: Avi Kivity <avi@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org Subject: [Qemu-devel] Re: [uq/master patch 2/5] kvm: add logging count to slots Date: Sun, 25 Apr 2010 16:29:45 +0200 [thread overview] Message-ID: <4BD451D9.4090209@web.de> (raw) In-Reply-To: <4BD44F13.3070000@redhat.com> [-- Attachment #1: Type: text/plain, Size: 1459 bytes --] Avi Kivity wrote: > On 04/25/2010 04:57 PM, Jan Kiszka wrote: >> >>> It's still a good idea. The current API assumes that there will be only >>> one slot-based client (or that multiple clients will keep the refcount >>> themselves). >>> >>> After the bytemap -> multiple bitmaps conversion this can be >>> extended to >>> each client getting its own bitmap (and therefore, s/refcount/list of >>> bitmaps/ and s/!refcount/list_empty()/). >>> >>> >> No concerns if >> - there is an existing use case for multiple clients, at least in >> qemu-kvm >> > > There isn't. But I don't like hidden breakage. It's (so far) an unproblematic API property we can document. I don't like changing APIs just for "there might be the case that...". > >> - the logging API is consistently converted, not just extended >> (IOW, migration_log is converted to logging_count) >> > > migration_log needs to remain global, since we want hotplug memory to > autostart logging. Can't follow yet, what will be the usage pattern of kvm_set_migration_log? Or would the hotplug code require a separate interface? Is it already the multi-client use case I'm looking for? > >> - someone signs he checked that current use of start/stop in qemu is >> completely symmetrical (I think to remember this used to be not the >> case, but I might be wrong) >> > > I remember this too. Marcelo? > Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-04-25 14:29 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-23 17:04 [uq/master patch 0/5] prepare for qemu-kvm's usage of upstream memslot code Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-23 17:04 ` [uq/master patch 1/5] vga: fix typo in length passed to kvm_log_stop Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-23 17:04 ` [uq/master patch 2/5] kvm: add logging count to slots Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-24 7:34 ` Jan Kiszka 2010-04-24 7:34 ` [Qemu-devel] " Jan Kiszka 2010-04-25 12:33 ` Avi Kivity 2010-04-25 12:33 ` [Qemu-devel] " Avi Kivity 2010-04-25 13:57 ` Jan Kiszka 2010-04-25 13:57 ` [Qemu-devel] " Jan Kiszka 2010-04-25 14:17 ` Avi Kivity 2010-04-25 14:17 ` [Qemu-devel] " Avi Kivity 2010-04-25 14:29 ` Jan Kiszka [this message] 2010-04-25 14:29 ` Jan Kiszka 2010-04-25 14:41 ` Avi Kivity 2010-04-25 14:41 ` [Qemu-devel] " Avi Kivity 2010-04-25 14:51 ` Jan Kiszka 2010-04-25 14:51 ` [Qemu-devel] " Jan Kiszka 2010-04-25 14:58 ` Avi Kivity 2010-04-25 14:58 ` [Qemu-devel] " Avi Kivity 2010-04-25 15:07 ` Jan Kiszka 2010-04-25 15:07 ` [Qemu-devel] " Jan Kiszka 2010-04-25 15:22 ` Avi Kivity 2010-04-25 15:22 ` [Qemu-devel] " Avi Kivity 2010-04-25 16:42 ` Jan Kiszka 2010-04-25 16:42 ` [Qemu-devel] " Jan Kiszka 2010-04-26 5:37 ` Avi Kivity 2010-04-26 5:37 ` [Qemu-devel] " Avi Kivity 2010-04-26 13:47 ` Marcelo Tosatti 2010-04-26 13:47 ` [Qemu-devel] " Marcelo Tosatti 2010-04-23 17:04 ` [uq/master patch 3/5] introduce leul_to_cpu Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-23 17:04 ` [uq/master patch 4/5] kvm: port qemu-kvm's bitmap scanning Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-23 17:04 ` [uq/master patch 5/5] introduce qemu_ram_map Marcelo Tosatti 2010-04-23 17:04 ` [Qemu-devel] " Marcelo Tosatti 2010-04-25 12:33 ` [uq/master patch 0/5] prepare for qemu-kvm's usage of upstream memslot code Avi Kivity 2010-04-25 12:33 ` [Qemu-devel] " Avi Kivity
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4BD451D9.4090209@web.de \ --to=jan.kiszka@web.de \ --cc=avi@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=mtosatti@redhat.com \ --cc=qemu-devel@nongnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.