Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area mapping rework

Juergen Gross <[email protected]> Tue, 25 Aug 2026 14:00:44 +0200

Newsgroups	gmane.comp.emulators.xen.devel
Message-ID	<[email protected]>

On 25.08.26 13:42, George Dunlap wrote:
> On Mon, Aug 24, 2026 at 10:02 AM Jan Beulich <[email protected]> wrote:
>> On 21.08.2026 17:17, George Dunlap wrote:
>>> On Fri, Aug 21, 2026 at 9:45 AM Jan Beulich <[email protected]> wrote:
>>>> On 20.08.2026 19:43, George Dunlap wrote:
>>>>> One point reviewers may want to look at specifically: patch 1 changes
>>>>> where the per-domain page-tables are allocated from, and its commit
>>>>> message discusses the (minor) NUMA-placement consequence.
>>>>
>>>> While I don't recall which recent patch (series) it was, I can't very well
>>>> say "no new xenheap allocations please" there without also saying so here.
>>>> I've read over patch 1's description, and while it tries to justify this
>>>> accordingly, I still remain concerned. I think we simply have to accept
>>>> the mapping overhead, to avoid allocating from a pool which - over time -
>>>> is representing a decreasing portion of total memory systems have (on
>>>> average, and not even considering systems with extremely sparse memory
>>>> layouts, and with perhaps PDX compression not doing good enough to
>>>> compensate).
>>>
>>> You should certainly have the same resistance to adding new xenheap
>>> allocations.  But looking at the numbers, I don't see that we're
>>> anywhere near the point where we say, "Absolutely no new xenheap
>>> allocations, regardless of the cost."
>>
>> Well, that depends, and in part on the longer term plans with ASI. It has
>> been my (silent) assumption that eventually the directmap would go away
>> altogether when ASI is in use, with the VA space freed (almost?) all
>> becoming available for vmap(). With the disappearance of directmap, the
>> xenheap would naturally disappear as well. Hence putting stuff there in
>> new work actually adds to our technical debt.
> 
> I do think that makes sense as a long-term goal.  Actually, I asked
> Fable to do an audit of xenheap allocations, asking it to classify
> them as to whether they needed xenheap's key properties (easy mfn <->
> va conversion, available in early boot), and it reckoned only about 4%
> of the allocations (by volume) in the example system I did numbers for
> needed xenheap-specific properties.  Lots of things just need *some*
> global mapping somewhere, and would probably actually overall benefit
> from being moved to the vmap, so they wouldn't be restricted to a
> single NUMA node.  Grant frames were the biggest chunk.

Please note that I'm currently working on a patch series which will need
to convert grant frames and some other xenheap allocations to use domheap
and vmap().

Currently this is just a proof of concept for Xen summit, but I expect
this to become mature after some feedback I hope to get there.


Juergen

OpenPGP_0xB0DE9DD628BF132F.asc (application/pgp-keys, 3.6 KB)

OpenPGP_signature.asc (application/pgp-signature, 495 B)