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() ? This is one area where we've got no XTF testing at all, and I probably ought to see about fixing that. ~Andrew
