On Mon, Aug 06, 2018 at 08:51:55AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Tian, Kevin [mailto:kevin.t...@intel.com] > > Sent: 06 August 2018 04:19 > > To: Roger Pau Monne <roger....@citrix.com>; Paul Durrant > > <paul.durr...@citrix.com> > > Cc: Jan Beulich <jbeul...@suse.com>; Stefano Stabellini > > <sstabell...@kernel.org>; Wei Liu <wei.l...@citrix.com>; George Dunlap > > <george.dun...@citrix.com>; Andrew Cooper > > <andrew.coop...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Tim > > (Xen.org) <t...@xen.org>; Julien Grall <julien.gr...@arm.com>; Suravee > > Suthikulpanit <suravee.suthikulpa...@amd.com>; xen-devel <xen- > > de...@lists.xenproject.org>; Brian Woods <brian.wo...@amd.com> > > Subject: RE: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu > > option > > > > > From: Roger Pau Monné [mailto:roger....@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.durr...@citrix.com> > > > > > Cc: Jan Beulich <jbeul...@suse.com>; Kevin Tian > > > <kevin.t...@intel.com>; > > > > > Stefano Stabellini <sstabell...@kernel.org>; Wei Liu > > > <wei.l...@citrix.com>; > > > > > George Dunlap <george.dun...@citrix.com>; Andrew Cooper > > > > > <andrew.coop...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; > > > Tim > > > > > (Xen.org) <t...@xen.org>; Julien Grall <julien.gr...@arm.com>; Suravee > > > > > Suthikulpanit <suravee.suthikulpa...@amd.com>; xen-devel <xen- > > > > > de...@lists.xenproject.org>; Brian Woods <brian.wo...@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.
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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
