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
