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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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?

Thanks,
Kevin

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