| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH 00/02] firmware changes as part of QEMU/Xen merge
Ian Pratt writes ("RE: [Xen-devel] [PATCH 00/02] firmware changes as part of
QEMU/Xen merge."):
> It's getting to the point where we might have to consider having two
> qemu binaries, one for compatibility, one that new VMs are
> transitioned on to.
Yes. But the "new" qemu binary will be, hopefully, upstream qemu's,
based on the work that Anthony is doing against upstream.
> Things are now so different that I'm worried that installed guests
> might complain even when just fresh booted on the new qemu.
That's a possibility. Some PCI IDs and device strings have changed.
> This is something that we'd need to test and devise
> workarounds. Trying to retain saved image compatibility with a
> single binary looks ugly.
It would be difficult. I guess we might be able to write an external
qemu save image translator.
The difficulty with the ACPI values is that ideally we want to be able
to use the same BIOS with both qemus and that means that the two qemus
either need to use the same values or there needs to be some
negotiation somewhere. We don't want to try to patch the "new" qemu
use the old values.
So the combinations which we want to work are:
qemu BIOS ACPI values notes
------------ ---------- ----------- -----------
upstream/new upstream's standard native qemu
upstream/new ours standard under Xen } save/restore
upstream/new upstream's standard in future } compat
old ours old Xen current Xen
This implies that we need to change "our" BIOS to be able to cope with
either arrangement.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home