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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.02.2026 15:20, Andrew Cooper wrote:
> On 04/02/2026 12:25 pm, Roger Pau Monne wrote:
>> The limitation of shared_info being allocated below 4G to fit in the
>> start_info field only applies to 32bit PV guests.  On 64bit PV guests the
>> start_info field is 64bits wide.  HVM guests don't use start_info at all.
> 
> All shared info?  HVM does use it, but doesn't see the MFN.

I think it's really start_info that is meant here, as that's where the
restriction comes from.

>> +    if ( virt_to_maddr(d->shared_info) >> 32 )
>> +    {
>> +        shared_info_t *prev = d->shared_info;
>> +
>> +        d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32));
>> +        if ( !d->shared_info )
>> +        {
>> +            d->shared_info = prev;
>> +            rc = -ENOMEM;
>> +            goto undo_and_fail;
>> +        }
>> +        put_page(virt_to_page(prev));
>> +        clear_page(d->shared_info);
> 
> I think copy_page() would be more appropriate.  That way there are fewer
> implicit ordering dependencies.

I'd strongly recommend against copy_page() here. If there was any data in
there that would need copying, it would need to be done field-wise, using
the compat xlat machinery. The layouts are different. It may be prudent to
assert that the original page is still completely zeroed.

Jan