On 05/25/2010 04:55 PM, Anthony Liguori wrote:
On 05/25/2010 08:38 AM, Avi Kivity wrote:
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust
in the face of poorly written block backends so if it's possible
to make it perform as well as a plugin, it's a preferable approach.
May be hard due to difficulty of exposing guest memory.
If someone did a series to add plugins, I would expect a very strong
argument as to why a shared memory mechanism was not possible or at
least plausible.
I'm not sure I understand why shared memory is such a bad thing wrt
KVM. Can you elaborate? Is it simply a matter of fork()?
fork() doesn't work in the with of memory hotplug. What else is there?
Is it that fork() doesn't work or is it that fork() is very expensive?
It doesn't work, fork() is done at block device creation time, which
freezes the child memory map, while guest memory is allocated at hotplug
time.
fork() actually isn't very expensive since we use MADV_DONTFORK
(probably fast enough for everything except realtime).
It may be possible to do a processfd() which can be mmap()ed by another
process to export anonymous memory using mmu notifiers, not sure how
easy or mergeable that is.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
