Re: [Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jul 31, 2018 at 08:18:36AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> > Of Roger Pau Monne
> > Sent: 27 July 2018 16:32
> > To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> > Cc: Kevin Tian <kevin.tian@xxxxxxxxx>; Stefano Stabellini
> > <sstabellini@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; George Dunlap
> > <George.Dunlap@xxxxxxxxxx>; Andrew Cooper
> > <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Tim
> > (Xen.org) <tim@xxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; Jan Beulich
> > <jbeulich@xxxxxxxx>; Roger Pau Monne <roger.pau@xxxxxxxxxx>
> > 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.pau@xxxxxxxxxx>
> > ---
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Julien Grall <julien.grall@xxxxxxx>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Cc: Tim Deegan <tim@xxxxxxx>
> > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > Cc: Kevin Tian <kevin.tian@xxxxxxxxx>
> > ---
> >  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.

Maybe the current iommu_inclusive_mapping could be mapped to
iommu=inclusive-mapping instead of iommu=inclusive and the new option
could be added as iommu=reserved-mapping?

That would work for PVH AFAICT.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel