[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] booting Xen from EFI


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Wed, 15 Jun 2011 15:55:52 +0100
  • Cc:
  • Delivery-date: Wed, 15 Jun 2011 07:56:38 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=JsVzLQznI9hEbuPCi+gBxNPSn5+iM/79+FN1AZbM5bgvn5zc82VV8XipZX1sB2S2zk ZBDdsdkIuIexnycor2WR4ffPryKTWPJk2p8y23vok/mpdYfU7Vo1wPUkAZ7PcO1WjpBZ 3xsl49seYAKTc9nfTEP6n0DnRJde63zcMewro=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwrbFINuE41vtGVuE+Zu5S0C4bf9A==
  • Thread-topic: [Xen-devel] booting Xen from EFI

On 15/06/2011 13:48, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> 1) While for obtaining the necessary firmware information
> XENPF_firmware_info was an obvious and natural fit, I'm not as
> certain for the to-be-implemented Dom0 access to the runtime
> services. I'm currently favoring a new XENPF_ sub-hypercall.

Fine.

> 2) The installation is part is still relatively unclear to me at this
> point: Linux irrespective of whether EFI is present, simply installs
> into /boot, relying on elilo to copy the necessary files over. As
> we're not going to use a secondary boot loader, we'd have to
> do this ourselves, but the mandated location is in
> <EFI-mountpoint>/efi/<vendor>/, and the <vendor> part
> ("SuSE" in our case) is what I don't see easily handled (as I
> wasn't able to find this stored in any system configuration file).

I suppose it will have to be specified via a Make config variable, and not
install (perhaps with a warning) if it isn't specified.

> 3) GrUB decompresses simple gzip-ed binaries (i.e. the traditional
> non-bzImage kernel), but with EFI Xen will need to do so itself.
> The most obvious choice would seem be to allow for all currently
> supported compression methods to not only be used inside a
> bzImage container, but also on a plain ELF binary.

I don't really understand the problem. As long as we don't get yet another
pile of decompressors in the tree I don't really care either.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.