Re: [PATCH v2] x86/domain: adjust limitation on shared_info allocation below 4G

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Feb 04, 2026 at 05:23:21PM +0000, Andrew Cooper wrote:
> On 04/02/2026 4:54 pm, Roger Pau Monné wrote:
> > On Wed, Feb 04, 2026 at 04:32:25PM +0100, Jan Beulich wrote:
> >> On 04.02.2026 16:12, Andrew Cooper wrote:
> >>> On 04/02/2026 3:01 pm, Roger Pau Monné wrote:
> >>>>>> +        share_xen_page_with_guest(virt_to_page(d->shared_info), d, 
> >>>>>> SHARE_rw);
> >>>>>> +        /* Ensure all references to the old shared_info page are 
> >>>>>> dropped. */
> >>>>>> +        for_each_vcpu( d, v )
> >>>>>> +            vcpu_info_reset(v);
> >>>>> switch_compat() can only occur on a domain with no memory.  How can we
> >>>>> have outstanding references?
> >>>> As Jan pointed out, it's not references, but stashed pointers to the
> >>>> previous shared_info page.  I've used the wrong wording here.
> >>> Yes, I saw that thread, but my question still stands.
> >>>
> >>> How can there be any this early in the domain's lifecycle?
> >> Can't (aren't) vCPU-s added ahead of adding memory?
> > At least on x86 when using xl/libxl the call to
> > XEN_DOMCTL_set_address_size happens after the call to
> > XEN_DOMCTL_max_vcpus, and the later calls vcpu_create() which sets the
> > pointer into the shared_info page for legacy (< 32) vCPUs.
> 
> Geez, that disaster of an interface still has spike traps we're falling
> foul of.
> 
> Please extend the comment to note the first 32 vcpu compatibility case.
> 
> But, combined with the format change (clear vs copy page), doesn't it
> mean there's an existing bug here?
> 
> Even without moving the shared_info page, aren't the cached pointers
> made wrong by switch_compat() ?

No, they are not wrong because the vcpu_info array is at the start of
shared_info, and it has the same size (64bytes) on both 32 and 64bits.
Hence the offsets into the different vcpu_info array elements are the
same regardless of bitness.

> This is one area where we've got no XTF testing at all, and I probably
> ought to see about fixing that.

Yeah, it's not great.

Thanks, Roger.