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

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 16/10/2013 17:00, Wei Liu ha scritto:
> On Wed, Oct 16, 2013 at 04:13:37PM +0200, Fabio Fantoni wrote:
> [...]
> > > > - 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.
> What do you mean by "in a single place"? They are two types of firmwares
> doing the same thing.
I mean ovmf with seabios inside it.
This way we have a unique section xen side which would manage ovmf (with 
both uefi and bios support).
This could be a support to every o.s. including ones that not support uefi.
Take a look at these for example:
http://www.seabios.org/pipermail/seabios/2013-January/005344.html
http://www.seabios.org/pipermail/seabios/2013-February/005423.html
Now it seems already on upstream git.
Ian Campbell also seems to be in the thread about it and xen:
http://www.seabios.org/pipermail/seabios/2013-February/005431.html

> > > > - 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.
> My shallow understanding is that, they (QEMU, hvmloader or any other
> firmwares) need to agree upon things. The point is they need to reach
> consesus, no matter which one is in charge. Even if QEMU / OVMF takes
> charge we would still face the same problem?
>
> On the other hand, it's critical for Xen to control those tables,
> because obviously we trust the hypervisor more than external code.
>
> Wei.
For the hvm domUs FWIK major part of devices are mainly managed by qemu.
I found this link that probably helps to clarify one of the actual 
problem and I think it is a smart idea to reconsider actual hvmloader 
section (even if only in some parts):
http://wiki.qemu.org/Features/ACPITableGeneration
> Once implemented, QEMU will be able to extend information passed to 
> Guest OS through ACPI tables without need for bios code changes. This 
> is widely desired as a way to avoid the churn and proliferation of 
> QEMU-specific interfaces associated with ACPI tables in bios code. 
Anyway if my idea is stupid and unuseful sorry for wasting your time.



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