From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [SeaBIOS] [RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM Date: Mon, 16 May 2011 09:44:28 +0100 Message-ID: <1305535468.31488.202.camel@zakaz.uk.xensource.com> References: <1305302343.31488.162.camel@zakaz.uk.xensource.com> <20110514133622.GB7008@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110514133622.GB7008@morn.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kevin O'Connor Cc: Anthony Perard , xen-devel , "seabios@seabios.org" List-Id: xen-devel@lists.xenproject.org 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. > > > > The following patches add very basic support for running SeaBIOS as the > > BIOS for a Xen HVM (fully virtualised) guest. > > 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? > These patches really do very little but they are sufficient to allow me > > to boot an HVM Linux guest to a prompt. SeaBIOS boots indirectly as an > > hvmloader payload with the first patch and directly if using the second > > (this second case requires a short patch series on the Xen side, see > > [0]). > > So, patch 1 in this thread is needed for indirect, and patch 1+2 in > this thread is needed for direct? Correct. > > This is presented more as a proof of concept since it's not obvious yet > > which approach will be best from either Xen or SeaBIOS's point of view. > > > > I'm generally leaning towards the second option since much of the setup > > currently done in hvmloader appears to be more down to the limitations > > of ROMBIOS than any particular design decision. For example SeaBIOS is > > perfectly happy loading option ROMS from the appropriate BAR so that > > aspect of hvmloader goes away entirely, similarly with building ACPI, > > SMBIOS, MP tables etc. I'd be glad to hear any opinions from either side > > on the matter. > > I'm okay with the second option. This is reminiscent of the > seabios+coreboot integration - there used to be an assembler loader > (called ADLO) that would do all sorts of weird things to get rombios > to load. One of my goals with SeaBIOS was to make that unnecessary. > > > 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? Or is gcc's whole program optimisation smart enough to spot when a global variable is never set != 0 and eliminate code as necessary? > Admittedly, CONFIG_COREBOOT doesn't do this today, but that's only > because I haven't gotten around to fixing it. (Ideally, there'd be > something like a CONFIG_EMULATORS (for qemu/kvm/bochs) and a > CONFIG_COREBOOT, and everything would be auto-detected if both were > enabled at the same time. > > > FWIW I expect (however naive it might be to make such predictions) the > > majority of the work to integrate SeaBIOS into Xen (other than test, > > test and more test with different OSes) will be to understand he > > differences in the various BIOS tables and figure out what is "just > > because", what represents real bug fixes on one side or the other, what > > is actually down to implementation details in Xen and what is down to > > differences between the old qemu-xen and upstream qemu. Having worked > > through all that I hope that actually finding a clean way to integrate > > the differences with SeaBIOS (or possibly qemu) will be comparatively > > trivial... > > Sounds good. > > -Kevin