[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework
From: |
Bhushan Bharat-R65777 |
Subject: |
Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework |
Date: |
Fri, 2 Dec 2011 18:35:24 +0000 |
> -----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;
> address@hidden; address@hidden; address@hidden; qemu-
> address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden; Yoder Stuart-B08248;
> address@hidden; address@hidden; linux-
> address@hidden; Wood Scott-B07421; address@hidden
> 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