Re: [Xen-devel] QEMU upstreaming: status and todo

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 5 Jan 2011, Keir Fraser wrote:
> On 05/01/2011 18:57, "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
> wrote:
> 
> >> Are the two really dependent on each other? Our virtual firmware seems to
> >> work okay now, it took a while to get there, and it now rarely needs to be
> >> fixed. I guess I don't care about the legacy rombios/vgabios bits too much,
> >> but I'd be unhappy about throwing away all our ACPI stuff. That was a pain
> >> to actually get working well. That means you can have
> >> tools/firmware/{rom,vga}bios if you want, but trickier to mess with 
> >> anything
> >> under tools/firmware/hvmloader.
> >  
> > I was proposing only to replace rombios: from a conversation we had with
> > the SeaBios maintainer at LPC, I think SeaBios can be made to work from
> > hvmloader without too much trouble. However I haven't read the code so
> > this needs to be tested.
> 
> If we could get rid of vgabios as well, and get rid of our dependency on
> vgabios, that would be nice. :-)

completely agree, unfortunately there is no replacement for vgabios yet


> Else I remain skeptical to be honest. But
> open to discussing it further, I may just need some more info on the
> advantages of the move.
> 

The advantages are code readability, having a common platform to avoid future
compatibility issues (like the ACPI io ports problems he had a little
while ago) and being able to reuse all the development that the SeaBios and
Qemu people are doing.
For example SeaBios supports 64 bit BAR addresses and is able to boot
from virtio devices (they might work on Xen in a not too distant
future).

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