qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resiz


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 14:44:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0


On 19/11/2014 14:28, Michael S. Tsirkin wrote:
> > 
> > qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0
> > 
> > what BIOS should the second qemu use?  the one that existed on qemu-2.0
> > time or the one that existed on qemu-2.2 time?  You can allow for
> > bugfixes, but not for big changes like moving where the acpi tables were
> > generated, etc, etc.
> 
> > I really think that we should use the BIOS from qemu-2.0 era.  And my
> > understanding is that you defend that we should use the qemu-2.2 era
> > BIOS.
> 
> Not only that.  We already do. And we don't intend to change that for 2.2.

Am I missing a part of the discussion?  When we migrate, the second QEMU
uses the BIOS from the first.

So:

qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0

   uses 2.0 BIOS

qemu-2.2 -M pc-2.0 -> qemu-2.0 -M pc-2.0

   uses 2.2 BIOS

Both should work, in general.  BIOS is rarely the reason for
incompatibilities.  However, breakage can happen, for example I know
that RHEL7 SeaBIOS does not work on RHEL6.  RHEL6 SeaBIOS works on
RHEL7, but it needs a couple workarounds.

Shipping a separate BIOS for different machine types is unrealistic and
pointless.  It would also be a good terrain for bug reports, unless you
also do things like "forbid creating -device megasas-gen2 on 2.1 because
it was introduced in 2.2".  Remember that libvirt keeps the same machine
type for the whole life of a virtual machine definition, even if other
parts of the hardware (e.g. disks or NICs) change.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]