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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-10-16 at 16:00 +0100, Wei Liu wrote:
> 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.
> 
> > >
> > >>- 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?

QEMU / OVMF is a false choice. The alternative to OVMF is SeaBIOS.

Qemu is present in both configurations.

> On the other hand, it's critical for Xen to control those tables,
> because obviously we trust the hypervisor more than external code. 

It's not so much about trust as the fact that the ACPI tables are
supposed to describe the physical hardware, which is defined by Xen
(i.e. the interrupt routing is implemented by Xen and Xen tells qemu
what to provide). Therefore it is correct for Xen to provide the ACPI
tables (via hvmloader), in the same way that the vendor of your physical
computer provides ACPI tables for that hardware.

Ian.


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