Re: [Xen-devel] [RFC] Dom0 PV IOMMU control design (draft A)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.04.14 at 18:38, <malcolm.crossley@xxxxxxxxxx> wrote:
> On 14/04/14 16:48, Jan Beulich wrote:
>>>>> On 14.04.14 at 17:03, <malcolm.crossley@xxxxxxxxxx> wrote:
>>> On 14/04/14 13:51, Konrad Rzeszutek Wilk wrote:
>>>> On Mon, Apr 14, 2014 at 01:12:07PM +0100, Malcolm Crossley wrote:
>>>>> On 11/04/14 18:50, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Apr 11, 2014 at 06:28:43PM +0100, Malcolm Crossley wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is a design for allowing Dom0 PV guests to control the IOMMU.
>>>> With the device driver domains I think you should also rename the
>>>> 'dom0' to device driver or 'hardware domain' - as this functionality
>>>> should be possible within an PV guest with PCI passthrough for example.
>>> Currently Xen only allows Dom0 IOMMU access to all (expect Xen) MFN's. 
>> 
>> Except in dom0-strict mode, which your proposal doesn't even
>> support. Yet mid/long term that mode should imo be what Dom0
>> should be run in by default.
>> 
> dom0-strict mode could be supported by validating the mfn's passed in
> via the map operation to belong to the DomU making the hypercall.
> 
> Also, if we modify the grant map hypercalls to allow dev_bus_addr of
> struct gnttab_map_grant_ref to be used as an input and output parameter
> then we can specify the required BFN mapping for grant map pages. If we
> also delay IOTLB flushes as part of batched grant map operations then
> performance should also be OK.
> 
> I believe the two changes above would should be enough to support
> 'driver domains'. Would you agree?

Yes, at a first glance this should be all that's needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel