This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1 of 3] Enable UEFI BIOS(OVMF) support in Xen-unstable HVM
From: Andrei Warkentin <andreiw@xxxxxxxxxxxx>
Date: Fri, 22 Jul 2011 13:38:27 -0500
Cc: edk2-devel@xxxxxxxxxxxxxxxxxxxxx, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jordan Justen <jljusten@xxxxxxxxx>, Bei Guan <gbtju85@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Mon, 25 Jul 2011 15:11:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA4F6617.1E6D5%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAEQjb-QbaJXHc+O_oJDrxBX1P-fyHjwnUs+KWxDD2dozoMEiUw@xxxxxxxxxxxxxx> <CA4F6617.1E6D5%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


Xen-devel mailing list