qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qem


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Sat, 07 Nov 2009 07:59:08 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Avi Kivity wrote:
So it's equivalent to enabling dirty tracking during live migration. In my mind, if the cost associated with hot plug is a fraction of the cost of live migration, we're in good shape.

I don't see why. Live migration is pretty expensive, but that doesn't mean NIC hotplug should be. Deployments where live migration isn't a concern (for example, performance critical guests that use device assignment) don't suffer the live migration penalty so they shouldn't expect to see a gratuitous NIC hotplug penalty that is a fraction of that.

Live migration is a feature that I expect will often be used in an automated fashion. IOW, there will be some background process that automatically migrates a VM to improve overall utilization in a cloud.

NIC hotplug, on the other hand, will almost always be initiated by a user. If there's a cost associated with it, at least it's driven by a user action so it's something a user can plan for.

Arguably, it's a much bigger problem for live migration.

It is. I once considered switching live migration to shadow pte dirty bit tracking instead of write protection, but ept doesn't have dirty bits, so this will only help a minority of deployments by the time it reaches users.

So vfork() is required, or in light of its man page and glowing recommendations from the security people, we can mark guest memory as shared on fork and use plain fork(), like we do for pre mmu notifier kernels.

Indeed.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]