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

[Juergen Gross <jgross@xxxxxxxx>]

On 25.08.26 13:42, George Dunlap wrote:
> On Mon, Aug 24, 2026 at 10:02 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > On 21.08.2026 17:17, George Dunlap wrote:
> > > On Fri, Aug 21, 2026 at 9:45 AM Jan Beulich <jbeulich@xxxxxxxx> 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

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature