Re: [PATCH] hvmloader: probe memory below 4G before allocation for OVMF

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of this memory
>> the original pages are getting lost while still potentially foreign mapped
>> in Dom0.
> 
> When there are pre-allocated pages - have they been orphaned? If
> so, shouldn't whoever populated them unpopulate rather than
> orphaning them? Or if not - how is the re-use you do safe?

There is no signal to the device model when that happens - it has no idea when 
the
memory it populated and hold a mapping to becomes suddenly unmapped in the 
guest.
Re-use is safe as the memory prepopulated before OVMF starts has not been put
in use yet until after it's finished initializing.

>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -398,6 +398,20 @@ int get_mem_mapping_layout(struct e820entry entries[], 
>> uint32_t *max_entries)
>>      return rc;
>>  }
>>  
>> +bool mem_probe_ram(xen_pfn_t mfn)
>> +{
>> +    uint32_t tmp, magic = 0xdeadbeef;
>> +    volatile uint32_t *addr = (volatile uint32_t *)(mfn << PAGE_SHIFT);
>> +
>> +    tmp = *addr;
>> +    *addr = magic;
>> +    if ( *addr != magic )
>> +        return 0;
>> +
>> +    *addr = tmp;
>> +    return 1;
>> +}
> 
> This looks to probe r/o behavior. If there was a ROM page pre-populated,
> wouldn't it then be equally lost once you populate RAM over it? And what
> if this is MMIO, i.e. writable but potentially with side effects?

I assume if the pages behind it are not r/w there is no other way to avoid
crashing immediately except go and repopulate on top. MMIO is a problematic
corner case I expect device model would try to avoid.

> Whether, as you suggest as an alternative, moving populating of this
> space to the tool stack is feasible I don't know. If it was, I would
> wonder though why it wasn't done like this in the first place.

I expect one complication is to know the type of firmware at the moment
domain is constructed to make sure area is populated for OVMF only. 

Igor