On 05/12/2019 16:57, Jan Beulich wrote: > On 05.12.2019 16:47, Andrew Cooper wrote: >> On 05/12/2019 15:34, Jan Beulich wrote: >>> Translated domains shouldn't see host physical addresses. While the >>> address is also not supposed to be handed back even to non-translated >>> domains when GNTMAP_device_map is not set (as explicitly stated by a >>> comment in the public header), PV kernels (Linux at least) assume the >>> field to get populated nevertheless. >> This really means that the public header needs correcting. The field >> may not have intended to escape out of Xen, but it is defacto part of >> the ABI now. > Well, that's one of two possible routes. The other is to have, like > you did suggest earlier on, a mode in which we behave more strictly, > and current Linux then wouldn't work on such a Xen until fixed.
I'm sorely tempted to introduce a "fully strict mode" right now, behind a command line option, which chops off all the bits which shouldn't be usable in their current form. However, nothing, not even dom0, will boot successfully, so it probably isn't a great idea right now. Also, we'd have an easier time starting from nothing and whitelisting ok things in, than attempt to locate everything that we should blacklist in the current configuration. > >>> (Similarly mapkind() should check only GNTMAP_device_map.) >> Is this comment stale, or have I misunderstood some of the reasoning? > It's certainly not stale. mapkind() is used to determine whether > IOMMU mapping adjustments are needed. With this, it should in > principle only consider whether the current operation would > possibly alter IOMMU mapping needs. What needs doing should, > according to my interpretation of the originally intended design, > only depend on current and prior requests with GNTMAP_device_map > set. That's all reasonable, but there are no edits to mapkind(), so I'm confused as to why this is present in the commit message. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
