|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 02/30] x86/mm: refuse to promote an L4 while the domain has no vCPU
On Mon, Oct 19, 2026 at 08:42:33PM +0100, George Dunlap wrote:
> init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the
> L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT
> L3 slot at domain creation") a PV domain gets that L3 with its first
> vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it
> earlier, with the domain, and release builds skip that unless memory
> hotplug is enabled or the host's memory reaches past the part of the
> directmap PV guests can see. So in release builds on most hosts, an L4
> promoted before XEN_DOMCTL_max_vcpus has created the domain's vCPUs gets
> a slot 260 entry made from a NULL page (0x803e900000000063), pointing
> far beyond the host's memory.
Won't it be more reliable long term to instead return an error from
init_xen_l4_slots() when the per-domain L3 page is not present?
It does seem like PV vCPU creation could change yet again in a way
that the per-domain L3 is not allocated there, and then the check
added in this patch will be moot. If we need the per-domain
page-table to be allocated by this point, let's test for that, not
indirectly testing whether vCPU 0 has been created.
I also wonder, this is for PV only, but I assume for correctness
purposes we should do the same check for HVM monitor tables also?
Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |