Re: [PATCH 0/4] Reintroduce OVMF support

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

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.