[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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.