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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

> --- 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?

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.

Jan