On Tue, Jul 31, 2018 at 09:27:03AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne > > Sent: 31 July 2018 09:16 > > To: Paul Durrant <paul.durr...@citrix.com> > > Cc: xen-devel@lists.xenproject.org; Kevin Tian <kevin.t...@intel.com>; > > Stefano Stabellini <sstabell...@kernel.org>; Wei Liu <wei.l...@citrix.com>; > > George Dunlap <george.dun...@citrix.com>; Andrew Cooper > > <andrew.coop...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Tim > > (Xen.org) <t...@xen.org>; Julien Grall <julien.gr...@arm.com>; Jan Beulich > > <jbeul...@suse.com> > > 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:xen-devel-boun...@lists.xenproject.org] On > > Behalf > > > > Of Roger Pau Monne > > > > Sent: 27 July 2018 16:32 > > > > To: xen-devel@lists.xenproject.org > > > > Cc: Kevin Tian <kevin.t...@intel.com>; Stefano Stabellini > > > > <sstabell...@kernel.org>; Wei Liu <wei.l...@citrix.com>; George Dunlap > > > > <george.dun...@citrix.com>; Andrew Cooper > > > > <andrew.coop...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; > > Tim > > > > (Xen.org) <t...@xen.org>; Julien Grall <julien.gr...@arm.com>; Jan > > Beulich > > > > <jbeul...@suse.com>; Roger Pau Monne <roger....@citrix.com> > > > > 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é <roger....@citrix.com> > > > > --- > > > > Cc: Andrew Cooper <andrew.coop...@citrix.com> > > > > Cc: George Dunlap <george.dun...@eu.citrix.com> > > > > Cc: Ian Jackson <ian.jack...@eu.citrix.com> > > > > Cc: Jan Beulich <jbeul...@suse.com> > > > > Cc: Julien Grall <julien.gr...@arm.com> > > > > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > > > Cc: Stefano Stabellini <sstabell...@kernel.org> > > > > Cc: Tim Deegan <t...@xen.org> > > > > Cc: Wei Liu <wei.l...@citrix.com> > > > > Cc: Kevin Tian <kevin.t...@intel.com> > > > > --- > > > > 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.
Yes, we already have a bunch of those, so then I think dom0-inclusive and dom0-reserved would be appropriate? dom0-inclusive-mapping or dom0-reserved-mapping seems too long. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
