Re: [Xen-devel] [PATCH 0/4] Reintroduce OVMF support

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 16/10/2013 14:51, Wei Liu ha scritto:
> On Wed, Oct 16, 2013 at 12:03:19PM +0200, Fabio Fantoni wrote:
> > Il 15/10/2013 18:40, Wei Liu ha scritto:
> > > This small series reintroduces OVMF support in Xen
> > >
> > > You can fetch working OVMF tree on:
> > > git://xenbits.xen.org/people/liuw/ovmf.git master
> > >
> > > Working changeset that can be sticked in Config.mk is:
> > > 8833370303d3bf3153760ee42760ef1b9b5c562
> > >
> > > Note that VNC doesn't work properly when using OVMF, but that's not OVMF's
> > > problem. This issue should be addressed in Xen and I'm working on that.
> > >
> > > Wei.
> > Thanks for work on it, when I tested it months ago there was lot of
> > problems.
> Could you elaborate on the problems you're seeing? I'm aware of the VNC
> not refreshing problem but that's not to be fixed in OVMF.
>
> > I think it would be good thing to give an eye to the links below to
> > improve the hvm part:
> >
> > - Integrate legacy bios support inside ovmf (I saw a draft on link
> > above and I not know actual progress, there was also discussion
> > about it on seabios mailing list)
> > http://git.infradead.org/users/dwmw2/edk2.git
> > http://git.infradead.org/users/dwmw2/seabios.git
> Hmm... I think this is orthogonal. We can get all those gravy new
> features when we refresh our own tree.
>
> Keep in mind that we're not forking EDK2. Actually we're trying to work
> closely with upstream - I fixed a upstream bug to make OVMF work with
> Xen before sending the series so in fact the tree I'm presenting is just
> vanilla upstream tree.
>
> The reason we have our own tree is that we need to have a central
> location where users can pull from. Also we would test our branch to
> avoid frustration.
Yes I don't want to fork ovmf, just check if there is already legacy 
bios support on upstream, otherwise keep an eye on it.
I think it is important to have both uefi and bios support in a single 
place in the future.
> > - Since this is a new/experimental section, it would be a better
> > path to move the actual 'static' data taken from hvmloader more
> > 'dynamics' or at least have theme generated from qemu.
> > This would lead in turn to a better support for all the new qemu
> > device/features and also to avoid eventual regressions with
> > ovmf/qemu newer versions.
> I don't see why OVMF would prevent you from using QEMU new device
> features, but I sort of get the idea of separating hvmloader and other
> firmwares. You could make an argument / request on xen-devel and ask
> George to keep track of it, then we will see what we can do.
>
> Wei.
Maybe I didn't explain myself well, I was talking about ACPI tables and 
all other static tables in hvmloader. I think it would be better to get 
these tables from OVMF/QEMU so that we don't need to update them in Xen 
every time something changes in new versions of OVMF/QEMU or particular 
devices (emulated or passthrough).
I don't know if what I have in mind is feasible and correct considering 
my lack of knowledge about it but if I understand correctly it would get 
rid of many problems with new versions of qemu or with optional devices 
affecting such part.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel