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

[Kevin O'Connor <kevin@xxxxxxxxxxxx>]

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?

Thanks.

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.

-Kevin

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