>>> On 31.07.18 at 10:27, <[email protected]> wrote: >> -----Original Message----- >> From: Roger Pau Monne >> Sent: 31 July 2018 09:16 >> To: Paul Durrant <[email protected]> >> Cc: [email protected]; Kevin Tian <[email protected]>; >> Stefano Stabellini <[email protected]>; Wei Liu <[email protected]>; >> George Dunlap <[email protected]>; Andrew Cooper >> <[email protected]>; Ian Jackson <[email protected]>; Tim >> (Xen.org) <[email protected]>; Julien Grall <[email protected]>; Jan Beulich >> <[email protected]> >> Subject: Re: [Xen-devel] [PATCH 2/4] iommu: generalize >> iommu_inclusive_mapping >> >> On Tue, Jul 31, 2018 at 08:18:36AM +0100, Paul Durrant wrote: >> > > -----Original Message----- >> > > From: Xen-devel [mailto:[email protected]] On >> Behalf >> > > Of Roger Pau Monne >> > > Sent: 27 July 2018 16:32 >> > > To: [email protected] >> > > Cc: Kevin Tian <[email protected]>; Stefano Stabellini >> > > <[email protected]>; Wei Liu <[email protected]>; George Dunlap >> > > <[email protected]>; Andrew Cooper >> > > <[email protected]>; Ian Jackson <[email protected]>; >> Tim >> > > (Xen.org) <[email protected]>; Julien Grall <[email protected]>; Jan >> Beulich >> > > <[email protected]>; Roger Pau Monne <[email protected]> >> > > Subject: [Xen-devel] [PATCH 2/4] iommu: generalize >> > > iommu_inclusive_mapping >> > > >> > > Introduce a new iommu=inclusive generic option that supersedes >> > > iommu_inclusive_mapping. This should be a non-functional change on >> > > Intel hardware, while AMD hardware will gain the same functionality of >> > > mapping almost everything below the 4GB boundary. >> > > >> > > Note that is a noop for ARM hardware. >> > > >> > > Signed-off-by: Roger Pau Monné <[email protected]> >> > > --- >> > > Cc: Andrew Cooper <[email protected]> >> > > Cc: George Dunlap <[email protected]> >> > > Cc: Ian Jackson <[email protected]> >> > > Cc: Jan Beulich <[email protected]> >> > > Cc: Julien Grall <[email protected]> >> > > Cc: Konrad Rzeszutek Wilk <[email protected]> >> > > Cc: Stefano Stabellini <[email protected]> >> > > Cc: Tim Deegan <[email protected]> >> > > Cc: Wei Liu <[email protected]> >> > > Cc: Kevin Tian <[email protected]> >> > > --- >> > > docs/misc/xen-command-line.markdown | 14 ++++++ >> > > xen/drivers/passthrough/arm/iommu.c | 4 ++ >> > > xen/drivers/passthrough/iommu.c | 6 +++ >> > > xen/drivers/passthrough/vtd/extern.h | 2 - >> > > xen/drivers/passthrough/vtd/iommu.c | 6 --- >> > > xen/drivers/passthrough/vtd/x86/vtd.c | 66 +------------------------ >> > > xen/drivers/passthrough/x86/iommu.c | 70 >> > > +++++++++++++++++++++++++++ >> > > xen/include/xen/iommu.h | 2 + >> > > 8 files changed, 97 insertions(+), 73 deletions(-) >> > > >> > > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen- >> > > command-line.markdown >> > > index 65b4754418..91a8bfc9a6 100644 >> > > --- a/docs/misc/xen-command-line.markdown >> > > +++ b/docs/misc/xen-command-line.markdown >> > > @@ -1198,6 +1198,17 @@ detection of systems known to misbehave >> upon >> > > accesses to that port. >> > > >> > > >> Enable IOMMU debugging code (implies `verbose`). >> > > >> > > +> `inclusive` >> > >> > This is a dom0 (or hwdom) specific setting so perhaps dom0-inclusive? >> > >> > Actually the dom0 iommu options are starting to get unwieldy as they are >> conflated with the general host iommu options so I think it may be >> worthwhile splitting things out into a separate 'dom0-iommu=' top level >> parameter at this stage. (My reasons are slightly selfish as I intend to add >> another dom0 iommu option to give it just reserved regions, to avoid >> unnecessary set-up if we know it will be using PV-IOMMU). >> >> Mapping just the reserved regions is what I actually do for PVH with >> iommu=inclusive (patch 4/4), so maybe it would make sense to speak about >> the >> naming here in order to use the same naming for PV and PVH. >> >> TBH I don't really like the dom0- prefix, the command line iommu >> options either apply to all domains or Dom0 only, having >> domu-inclusive for example makes no sense IMO. > > No, I think there are some options that you may want to apply to dom0 only, > but these are more like the dom0_mem or dom0_max_vpus options. Particularly, > the inclusive option is probably something that is only desirable for dom0. > Clearly dom0-passthrough and dom0-strict are already defined to relate to > dom0 > only, and options such as 'reserved' should only be specific on the command > line in relation to dom0 IMO. For other domains such an option should be > specified via xl.cfg.
So perhaps "dom0=iommu-inclusive" etc? Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
