Le 05/08/2026 à 12:09, Andrew Cooper a écrit :
On 05/08/2026 10:44 am, Jan Beulich wrote:On 29.07.2026 11:59, Teddy Astie wrote:Interrupt remapping entries often needs to be accessed, and we're creating pointers to it on demand, which brings a lot of complexity (e.g GET_IREMAP_ENTRY() macro), move it to xenheap such that it's persistently mapped and we won't have to worry about mapping and unmapping individual intremap table pages.Afaic: No movement from domheap to xenheap except for _very_ good reasons. For the case here that is - maybe establish a permanent mapping using vmap(), but no change in where the memory is to come from. Whether such a permanent mapping is really worthwhile may also want supporting by numbers. You say "often", but you don't qualify / quantify this any further.
I think the reduction the complexity of the logic is a good reason into using a persistent mapping here (especially since it's not a particularly large one).
To expand on the "why" a bit more. For systems with all RAM below the 4T boundary, domheap and xenheap are equivalent. We have 5T of directmap, but xenheap allocations have a width restriction which is a power-of-2. For systems with any RAM above the 4T boundary, you can't have xenheap allocations be NUMA-local for all NUMA nodes. As for "often", the IRTEs are modified every time a vCPU moves to a different PCPU, because the target addresses need updating. While it probably doesn't matter much today, in the context of ASI it's something which would want mapping permanently, rather than on-demand.
Ok, so domheap with vmap would be preferable here.
~Andrew>
Teddy
OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
