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.
