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