[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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)

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:
Now it seems already on upstream git.
Ian Campbell also seems to be in the thread about it and xen:

- 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.

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.


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):
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.