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

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

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.

Thanks, Roger.

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