Re: [PATCH v5 02/45] x86/mm: refuse to promote an L4 while the domain has no per-domain L3

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.11.2026 15:02, George Dunlap wrote:
> On Mon, Nov 2, 2026 at 9:50 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 30.10.2026 18:11, George Dunlap wrote:
>>> On Thu, Oct 29, 2026 at 7:47 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> Independent of that, how about pulling hvm_domain_initialise()'s
>>>> create_perdomain_mapping() up into arch_domain_create() instead of the
>>>> code additions you do?
>>>
>>> So, let's see if we can solve it "properly".  Constraints:
>>>
>>> - Eventually, not all domains will have a domain-wide L3; some will
>>> only have per-vCPU L3s.
>>>
>>> - init_xen_l4_slots needs a domain always, but only needs a vcpu to
>>> get the L3 of vcpu_pt domains.
>>>
>>> - PV vcpu_pt domains don't need an L3 installed after
>>> init_xen_l4_slots; they need to run on a clone of the L4 anyway.
>>>
>>> So by the end of the series, we could arrange it like this:
>>>
>>> non-vcpu_pt domains always allocate d->arch.l3_perdomain in
>>> arch_domain_create.  vcpu_pt domains always allocate
>>> v->arch.l3_perdomain in arch_vcpu_create.
>>>
>>> Have __init_xen_l4_slots() take a domain and an L3; if the L3 is NULL,
>>> leave the perdomain slot empty.
>>>
>>> Have init_xen_l4_slots() take a vcpu.  BUG_ON(is_hvm_vcpu(v) &&
>>> v->arch.asi.vcpu_pt && !v->arch.l3_perdomain), then pass the
>>> appropriate l3 into __init_xen_l4_slots().
>>>
>>> Have init_xen_l4_slots_pv() take a domain, and always pass the domain
>>> and d->arch.l3_perdomain to __init_xen_l4_slots.  This will be NULL
>>> for PV vcpu_pt domains, but that's fine.
>>>
>>> Then promote_l4_table() calls init_xen_l4_slots_pv() with a domain,
>>> and loses both the checks at the top.
>>>
>>> There are corner cases to sort out, like how idle domains get an L3;
>>> but overall I think this makes everything more robust.
>>>
>>> Thoughts?
>>
>> Sounds plausible to me.
> 
> This has beeen done.  It required some refactoring of later patches.
> These have all been tested and skimmed, but haven't been over with a
> fine-tooth comb again, so there's a risk of LLM quirks.  Do you mind
> if I post what I have now, so people can look at it this week if the
> chance affords?  Otherwise I won't be able to post it until next week
> at the earliest.

Sure, feel free to go ahead. It's a long series, but still better to
have the up-to-date version on list / under review.

Jan