On 07.02.2024 10:14, Roger Pau Monné wrote: > On Tue, Feb 06, 2024 at 12:49:08PM +0100, Jan Beulich wrote: >> On 01.02.2024 18:01, Roger Pau Monne wrote: >>> Currently when a unity range overlaps with memory being used as RAM by the >>> hypervisor the result would be that the IOMMU gets disabled. However that's >>> not enough, as even with the IOMMU disabled the device will still access the >>> affected RAM areas. >> >> Hmm, no, I think this is going too far. Not the least because it is >> s/will/may/. But also because if we really wanted such behavior, we >> ought to also parse the respective ACPI tables when the "iommu=off". > > I guessed so, hence why it's the last patch in the series. TBH I > think it's very unlikely that such system exist.
And you think so despite knowing that on some systems one needs to manually specify RMRR regions? >>> Doing so also allows to simplify the code and use a switch over the reported >>> memory type(s). >> >> I'm afraid this isn't right either: page_get_ram_type() can set >> multiple bits in its output. > > It can indeed. But if the only bit set is RAM_TYPE_CONVENTIONAL then > the page will be handled as RAM, and that's where Xen would be in > trouble if a device is also using such page as a unity map. > > If the page however is RAM_TYPE_CONVENTIONAL | RAM_TYPE_RESERVED then > the RESERVED type will take over the whole page, and it's no longer an > issue to have a unity range covering it. Okay, if this is intentional, than saying so in a code comment would imo help quite a bit. Jan
