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: [SeaBIOS] [Xen-devel] Re: [RFC] [PATCH 0/2] Basic SeaBIOS support fo

To: Kevin O'Connor <kevin@xxxxxxxxxxxx>
Subject: Re: [SeaBIOS] [Xen-devel] Re: [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 27 May 2011 10:27:14 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "seabios@xxxxxxxxxxx" <seabios@xxxxxxxxxxx>
Delivery-date: Fri, 27 May 2011 06:11:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110527012001.GA374@xxxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1305302343.31488.162.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110514133622.GB7008@xxxxxxxxxxxxxxxx> <1305535468.31488.202.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110516233901.GA12092@xxxxxxxxxxxxxxxx> <1305647948.20907.72.camel@xxxxxxxxxxxxxxxxxxxxxx> <1306147478.20576.85.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110524001759.GC28567@xxxxxxxxxxxxxxxx> <1306234927.20576.155.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110525024457.GB25115@xxxxxxxxxxxxxxxx> <1306422817.775.48.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110527012001.GA374@xxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2011-05-27 at 02:20 +0100, Kevin O'Connor wrote:
> On Thu, May 26, 2011 at 04:13:37PM +0100, Ian Campbell wrote:
> > On Tue, 2011-05-24 at 22:44 -0400, Kevin O'Connor wrote:
> > > On Tue, May 24, 2011 at 12:02:07PM +0100, Ian Campbell wrote:
> > > > Would that involve pulling a bunch of mainboard specific stuff from
> > > > coreboot into SeaBIOS?
> > > 
> > > The idea - when it was last raised - was to provide raw info in a
> > > coreboot specific manor (via the "coreboot tables"), and then have
> > > SeaBIOS populate ACPI/SMBIOS/MPTable/etc. from that info.  It was
> > > never pursued.
> > 
> > Speaking of coreboot tables... I also need to pass some start of day
> > info into seabios (ACPI tables, e820 etc). Currently I just used a
> > little ad-hoc data structure at a known physical address but I wonder if
> > perhaps I should/could reuse the coreboot table datastructures? They are
> > existing and well defined and I suppose they are pretty static, but I
> > don't want to add any additional compatibility burden if you guys would
> > rather avoid it.
> Will Xen support the fw_cfg interface?

I don't think so, at least not in general. (fw_cfg is the qemu thing on
ports 0x510/511, right?)

I don't think the qemu instance in a Xen domain has all the info it
would need in order to provide the tables.

> Another thing to consider
> would be if coreboot+SeaBIOS in place of hvmloader would be a fit.  (I
> don't have a good feel for what hvmloader does to judge that.)

I think hvmloader contains a subset of coreboot's functionality. I've
wondered about possibly using coreboot in the future, but I think that
would be a separate project.

> Using the coreboot tables in Xen seems a bit odd, but I can't say it
> would cause a problem.

The existing ad-hoc structure I've defined is:
        struct xen_seabios_info {
            char signature[14]; /* XenHVMSeaBIOS\0 */
            u16 length;
            u32 acpi_rsdp;
            u32 mptable;
            u32 e820_nr;
            struct e820entry e820[128];
            u8 checksum;
so I was mainly thinking of e.g. CB_TAG_MEMORY along with CB_MEM_TABLE.

I think I'll stick with defining a structure myself, these things are
all discoverable via signatures so we can always transition in the


Xen-devel mailing list