[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 
memory it populated and hold a mapping to becomes suddenly unmapped in the 
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. 




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.