On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote: > On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote: > > On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote: > > > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote: > > > > > > Handling it through fds is a good idea. This makes sure that everything > > > > belongs to one process. I am not really sure yet if we go the way to > > > > just bind plain groups together or if we create meta-groups. The > > > > meta-groups thing seems somewhat cleaner, though. > > > > > > I'm leaning towards binding because we need to make it dynamic, but I > > > don't really have a good picture of the lifecycle of a meta-group. > > > > In my view the life-cycle of the meta-group is a subrange of the > > qemu-instance's life-cycle. > > I guess I mean the lifecycle of a super-group that's actually exposed as > a new group in sysfs. Who creates it? How? How are groups dynamically > added and removed from the super-group? The group merging makes sense > to me because it's largely just an optimization that qemu will try to > merge groups. If it works, great. If not, it manages them separately. > When all the devices from a group are unplugged, unmerge the group if > necessary. Right. The super-group thing is an optimization. > We need to try the polite method of attempting to hot unplug the device > from qemu first, which the current vfio code already implements. We can > then escalate if it doesn't respond. The current code calls abort in > qemu if the guest doesn't respond, but I agree we should also be > enforcing this at the kernel interface. I think the problem with the > hard-unplug is that we don't have a good revoke mechanism for the mmio > mmaps. For mmio we could stop the guest and replace the mmio region with a region that is filled with 0xff, no? Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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
