[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 14:51, Wei Liu ha scritto:
On Wed, Oct 16, 2013 at 12:03:19PM +0200, Fabio Fantoni wrote:
Il 15/10/2013 18:40, Wei Liu ha scritto:
This small series reintroduces OVMF support in Xen

You can fetch working OVMF tree on:
git://xenbits.xen.org/people/liuw/ovmf.git master

Working changeset that can be sticked in Config.mk is:
8833370303d3bf3153760ee42760ef1b9b5c562

Note that VNC doesn't work properly when using OVMF, but that's not OVMF's
problem. This issue should be addressed in Xen and I'm working on that.

Wei.
Thanks for work on it, when I tested it months ago there was lot of
problems.
Could you elaborate on the problems you're seeing? I'm aware of the VNC
not refreshing problem but that's not to be fixed in OVMF.

I think it would be good thing to give an eye to the links below to
improve the hvm part:

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


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



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


 


Rackspace

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