> -----Original Message----- > From: Wood Scott-B07421 > Sent: Friday, December 02, 2011 11:57 PM > To: Bhushan Bharat-R65777 > Cc: Stuart Yoder; Alex Williamson; Alexey Kardashevskiy; > aafabbri@xxxxxxxxx; kvm@xxxxxxxxxxxxxxx; pmac@xxxxxxxxxxx; qemu- > devel@xxxxxxxxxx; joerg.roedel@xxxxxxx; konrad.wilk@xxxxxxxxxx; > agraf@xxxxxxx; dwg@xxxxxxxxxxx; chrisw@xxxxxxxxxxxx; Yoder Stuart-B08248; > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; avi@xxxxxxxxxx; linux- > pci@xxxxxxxxxxxxxxx; Wood Scott-B07421; benve@xxxxxxxxx > Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework > > On 12/02/2011 12:11 PM, Bhushan Bharat-R65777 wrote: > > How do we determine whether guest is ready or not? There can be > multiple device get ready at different time. > > The guest makes a hypercall with a device handle -- at least that's how > we do it in Topaz. Yes, it is ok from hcall with device handle perspective. But I could not understood how cleanly this can be handled with the idea of enabling iommu when guest is ready. Thanks -Bharat > > > Further if guest have given the device to it user level process or its > guest. Should not there be some mechanism for a guest to enable/disable > on per device or group? > > Yes, the same mechanism can be used for that -- though in that case we'll > also want the ability for the guest to be able to control another layer > of mapping (which will get quite tricky with PAMU's limitations). > This isn't really VFIO's concern, though (unless you're talking about > the VFIO implementation in the guest). May be thinking too ahead, but will not something like this will be needed for nested virtualization? Thanks -Bharat -- 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
