RE: [Xen-devel] [PATCH 00/02] firmware changes as part of QEMU/Xen merge.

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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