[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |