Re: [Xen-devel] [PATCH 1 of 3] Enable UEFI BIOS(OVMF) support in Xen-unstable HVM

[Andrei Warkentin <andreiw@xxxxxxxxxxxx>]

Hi Keir,

On Fri, Jul 22, 2011 at 11:38 AM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:

> Looks pretty decent. I wonder why you need to change get_shared_info() --
> the existing mapping location is unused at the time hvmloader runs, and you
> instead map it over the top of a page of RAM. If you want shared_info mapped
> elsewhere, you can map it wherever you like as soon as your BIOS payload
> takes over.
>

The problem is that this page lies in an unsafe for OVMF area (right
below 4GB). In a typical PC environment,
you have the firmware ROM decoding the physical address space right
below 4GB, and it also has a chunk (~64-128k) shadowed below 1MB for
legacy reasons. The EFI firmware bootstrap code is written with the
assumption that it can transfer control to code < 4GB that will
finalize the 16->PM-(>LM if 64) transitions and call C code. The
get_shared_info page overlaps code we copy up below 4GB. This is why
it was moved to a safer region.

Effectively, I split the allocator into two portions, since it's
solving two distinct problems -
1) Allocate a safe range of memory - this is used both for RAM
allocation and for allocating ranges where "special" pages like
get_shared_info page live.
2) Back gmfns outside the allocator range with RAM. Because we need to
place the firmware image at a special location (4GB - sizeof(image)),
we need to ensure those
    gmfns actually have backing store.

> I'd also need to see what you use mem_back_ram() for, and maybe give it a
> better name, but I'm not against extracting that functionality into a
> function for the use of BIOS-specific handlers if the use is sane.

EFI is different from legacy ROM in that it doesn't just live below
1MB and the firmware image blob lives < 4GB, so we need to ensure
those pages are backed with RAM. Hence, mem_back_ram is simply
refactored out from the the old allocator.

Thanks,
A

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel