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


[Xen-devel] Re: [SeaBIOS] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xe

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [SeaBIOS] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM
From: Kevin O'Connor <kevin@xxxxxxxxxxxx>
Date: Mon, 16 May 2011 19:39:01 -0400
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "seabios@xxxxxxxxxxx" <seabios@xxxxxxxxxxx>
Delivery-date: Tue, 17 May 2011 16:42:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1305535468.31488.202.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <1305302343.31488.162.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110514133622.GB7008@xxxxxxxxxxxxxxxx> <1305535468.31488.202.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, May 16, 2011 at 09:44:28AM +0100, Ian Campbell wrote:
> On Sat, 2011-05-14 at 14:36 +0100, Kevin O'Connor wrote:
> > On Fri, May 13, 2011 at 04:59:03PM +0100, Ian Campbell wrote:
> > > As you may know we (the Xen project) are hoping to transition to SeaBIOS
> > > at the same time as we transition to the recently upstreamed qemu
> > > support for Xen.
> > Just so I understand, is this needed for Xen pre-qemu integration,
> > post-qemu integration, or both?
> We'd like to have all the pieces in place for the Xen 4.2 release, which
> isn't really planned out yet, but I think the late end of this year
> would be a reasonable bet. I think we can be flexible around the order
> integration happens in, we simply won't flip the default until
> everything is in place.
> Is that what you meant by post/pre-qemu integration?

I was referring to your statement above about "transition to SeaBIOS
at the same time as we transition to the recently upstreamed qemu
support for Xen".  I wasn't sure if your patches are tied to that
"upstreamed qemu" work or not.

> > > One problem I have with the first patch is that I'm lacking the
> > > vocabulary to describe the configuration which is currently represented
> > > by COREBOOT=n. I wanted to switch the coreboot option to a Kconfig
> > > choice (so I can add XEN as another option) so I needed a name for the
> > > other option. I went with GENERIC but I've no idea if that is accurate.
> > > Is "EMULATOR" more accurate? Suggestions welcome.
> > 
> > The preferred approach would be to autodetect Xen at runtime and use
> > that to control the code flow.  A CONFIG_XEN option would then only be
> > used to reduce the overall code size for those that do not need Xen
> > support and want a smaller binary.
> Sure. I'll change things to do it that way then.
> As well as CONFIG_XEN should I be adding a xen_present variable which is
> set dynamically and used as appropriate? If so then is a #ifdef to
> define it to 0 in the !CONFIG_XEN case (to allow the dead code to be
> eliminated) necessary?


I'd suggest something like a "int usingXen(void)" inline which reads
"xen_present".  The first couple of lines of usingXen() could do a "if
(!CONFIG_XEN) return 0".  Though - if the code is as simple as the
patches you've already sent - then you can leave it on permanently for
emulators (ie, do "if (CONFIG_COREBOOT)") - I'm not worried about a
few extra bytes for Xen in the emulator case.

>Or is gcc's whole program optimisation smart
> enough to spot when a global variable is never set != 0 and eliminate
> code as necessary?

I don't think it's that smart.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>