All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: Andrei Warkentin <andreiw@motorola.com>
Cc: edk2-devel@lists.sourceforge.net,
	Xen Devel <xen-devel@lists.xensource.com>,
	Jordan Justen <jljusten@gmail.com>, Bei Guan <gbtju85@gmail.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [PATCH 1 of 3] Enable UEFI BIOS(OVMF) support in Xen-unstable HVM
Date: Sat, 23 Jul 2011 07:53:50 +0100	[thread overview]
Message-ID: <CA502E8E.1E715%keir.xen@gmail.com> (raw)
In-Reply-To: <CALfQTu5qNSE3_=NqZQ7Hz0SZJbEAt0WC8E-66br9VGA9oykYVQ@mail.gmail.com>

On 22/07/2011 19:38, "Andrei Warkentin" <andreiw@motorola.com> wrote:

> On Fri, Jul 22, 2011 at 11:38 AM, Keir Fraser <keir.xen@gmail.com> 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.

Okay, we can work with this easily enough.

 -- Keir

  reply	other threads:[~2011-07-23  6:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 16:23 [PATCH 1 of 3] Enable UEFI BIOS(OVMF) support in Xen-unstable HVM Bei Guan
2011-07-22 16:38 ` Keir Fraser
2011-07-22 18:38   ` Andrei Warkentin
2011-07-23  6:53     ` Keir Fraser [this message]
2011-07-23  9:06       ` Keir Fraser
2011-07-23 15:18         ` Bei Guan
2011-07-23 16:50           ` Keir Fraser
2011-07-25 14:03 ` Konrad Rzeszutek Wilk
2011-07-25 14:17   ` Keir Fraser
2011-07-25 15:12   ` Bei Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA502E8E.1E715%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=Tim.Deegan@citrix.com \
    --cc=andreiw@motorola.com \
    --cc=edk2-devel@lists.sourceforge.net \
    --cc=gbtju85@gmail.com \
    --cc=jljusten@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.