[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) http://git.infradead.org/users/dwmw2/edk2.git http://git.infradead.org/users/dwmw2/seabios.gitHmm... 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |