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

[Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>]

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?


>> To not change the current security implications of the feature I would 
>> prefer that 'hardware domain' support was added as a separate design.
> 
> I think you mean "driver domain" here; "hardware domain" is the
> generalized term for Dom0 (and with most of the respective changes
> for the latter already in the staging tree I think you ought to no
> longer use the term "Dom0" here).

You are right, I did mean 'driver domain' for the security implications.
I will replace references to domain 0 with hardware domain in the next
draft.
> 
> Jan
> 


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