Re: [PATCH v2 2/5] iommu: introduce dom0-iommu option

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Sent: 06 August 2018 04:19
> To: Roger Pau Monne <roger.pau@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Wei Liu <wei.liu2@citrix.com>; George Dunlap
> <George.Dunlap@citrix.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Tim
> (Xen.org) <tim@xen.org>; Julien Grall <julien.grall@arm.com>; Suravee
> Suthikulpanit <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>; Brian Woods <brian.woods@amd.com>
> Subject: RE: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu
> option
> 
> > From: Roger Pau Monné [mailto:roger.pau@citrix.com]
> > Sent: Friday, August 3, 2018 5:33 PM
> >
> > On Fri, Aug 03, 2018 at 10:14:49AM +0100, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Roger Pau Monne
> > > > Sent: 03 August 2018 10:09
> > > > To: Paul Durrant <Paul.Durrant@citrix.com>
> > > > Cc: Jan Beulich <JBeulich@suse.com>; Kevin Tian
> > <kevin.tian@intel.com>;
> > > > Stefano Stabellini <sstabellini@kernel.org>; Wei Liu
> > <wei.liu2@citrix.com>;
> > > > George Dunlap <George.Dunlap@citrix.com>; Andrew Cooper
> > > > <Andrew.Cooper3@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>;
> > Tim
> > > > (Xen.org) <tim@xen.org>; Julien Grall <julien.grall@arm.com>; Suravee
> > > > Suthikulpanit <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> > > > devel@lists.xenproject.org>; Brian Woods <brian.woods@amd.com>
> > > > Subject: Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-
> iommu
> > > > option
> > > >
> > > > On Fri, Aug 03, 2018 at 10:05:19AM +0100, Paul Durrant wrote:
> > > > > Actually I wonder whether we should rename 'inclusive' to 'reserved'.
> > > > Essentially 'none', 'strict' or 'relaxed' are all about mappings of RAM,
> > and then
> > > > we need to decide whether to map the E820 reserved regions. So I
> think
> > the
> > > > inclusive map as it stands today is equivalent to 'relaxed' + 'reserved'.
> > > >
> > > > Hm, not exactly. inclusive (iommu_inclusive_mapping) right now maps
> > > > everything except unusable regions. That's way more than just
> mapping
> > > > reserved regions. If we want to keep this behaviour while introducing
> > > > an option to map only reserved regions we need both an inclusive and a
> > > > reserved option.
> > > >
> > >
> > > Ok, how about:
> > >
> > > inclusive -> all E820 ranges except unusable or ram
> >
> > inclusive ATM also maps holes. So it would be all memory ranges except
> > those marked as unusable or in use by Xen.
> >
> > > reserved -> all E820 reserved ranges
> > >
> > > then
> > >
> > > strict -> all ram ranges belonging to dom0
> > > relaxed -> all ram ranges
> > > none -> no ram ranges
> > >
> > > The problem then is what does, say, reserved + no-inclusive mean? I
> > guess we could have a flag for each non ram E820 range type?
> >
> > reserved + no-inclusive would make sense for a PV Dom0 running on
> > Intel hardware in order to map only the reserved regions instead of
> > mapping almost everything below 4GB by default.
> >
> > What about the following description of the options, do you think it's
> > clear enough?
> >
> > > `= List of [ none | strict | relaxed | inclusive | reserved ]`
> >
> > * `none`: disables DMA remapping for Dom0.
> >
> > The following two options control how RAM regions are mapped in the
> > iommu for
> > Dom0:
> >
> > * `strict`: sets up DMA remapping only for the memory Dom0 actually got
> >   assigned.
> >
> > * `relaxed`: sets DMA remapping for all the host RAM except regions in use
> > by
> >   Xen. This is the default iommu behaviour.
> >
> > Note that all the above options are mutually exclusive. Specifying more
> > than
> > one on the `dom0-iommu` command line will result in undefined behavior.
> >
> > The following options control whether non-RAM regions are added to the
> > Dom0
> > iommu tables. Note that they can be prefixed with `no-` to effect the
> > inverse
> > meaning:
> >
> > * `inclusive`: sets up DMA remapping for all the non-RAM memory below
> > 4GB
> >   except for unusable ranges. Use this to work around firmware issues
> > providing
> >   incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for
> > IOMMU
> >   accesses for Dom0, with this option all pages up to 4GB, not marked as
> >   unusable in the E820 table, will get a mapping established. Note that this
> >   option is only applicable to a PV Dom0 and is enabled by default on Intel
> >   hardware.
> >
> > * `reserved`: sets up DMA remapping for all the reserved regions in the
> > memory
> >   map for Dom0. Use this to work around firmware issues providing
> > incorrect
> >   RMRR or IVMD entries. Rather than only mapping RAM pages for IOMMU
> > accesses
> >   for Dom0, all memory regions marked as reserved in the memory map
> > that don't
> >   overlap with any MMIO region from emulated devices will be identity
> > mapped.
> >   This option maps a subset of the memory that would be mapped when
> > using the
> >   `inclusive` option. This option is available to a PVH Dom0 and is enabled
> > by
> >   default on Intel hardware.
> >
> 
> above makes it clear now. Just a side question. Is there also value of applying
> 'reserved' option to PV Dom0?

Absolutely. I don't think the text implies it's not available for PV dom0, just that (unlike 'inclusive') it is also available to PVH dom0.

  Paul

> 
> Thanks,
> Kevin

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