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

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

On Mon, Aug 06, 2018 at 08:51:55AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> > Sent: 06 August 2018 04:19
> > To: Roger Pau Monne <roger.pau@xxxxxxxxxx>; Paul Durrant
> > <Paul.Durrant@xxxxxxxxxx>
> > Cc: Jan Beulich <JBeulich@xxxxxxxx>; 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>; Suravee
> > Suthikulpanit <suravee.suthikulpanit@xxxxxxx>; xen-devel <xen-
> > devel@xxxxxxxxxxxxxxxxxxxx>; Brian Woods <brian.woods@xxxxxxx>
> > Subject: RE: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu
> > option
> > 
> > > From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> > > 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@xxxxxxxxxx>
> > > > > Cc: Jan Beulich <JBeulich@xxxxxxxx>; 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>; Suravee
> > > > > Suthikulpanit <suravee.suthikulpanit@xxxxxxx>; xen-devel <xen-
> > > > > devel@xxxxxxxxxxxxxxxxxxxx>; Brian Woods <brian.woods@xxxxxxx>
> > > > > 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.

For a PV Dom0 using just:

dom0-iommu=reserved

On Intel hardware doesn't change the behaviour, since reserved is a
subset of inclusive. OTOH, using something like:

dom0-iommu=no-inclusive,reserved

Will have an effect even on Intel hardware, and the memory mapped will
be limited to reserved regions only.

Roger.

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