[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.