Re: [Qemu-devel] 1.1.1 -> 1.1.2 migrate /managedsave issue

[Doug Goldstein]

On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori <address@hidden> wrote:
> Avi Kivity <address@hidden> writes:
>
>> On 10/22/2012 09:04 AM, Philipp Hahn wrote:
>>> Hello Doug,
>>>
>>> On Saturday 20 October 2012 00:46:43 Doug Goldstein wrote:
>>>> I'm using libvirt 0.10.2 and I had qemu-kvm 1.1.1 running all my VMs.
>>> ...
>>>> I had upgraded to qemu-kvm 1.1.2
>>> ...
>>>> qemu: warning: error while loading state for instance 0x0 of device 'ram'
>>>> load of migration failed
>>>
>>> That error can be from many things. For me it was that the PXE-ROM images 
>>> for
>>> the network cards were updated as well. Their size changed over the next
>>> power-of-two size, so kvm needed to allocate less/more memory and changed
>>> some PCI configuration registers, where the size of the ROM region is 
>>> stored.
>>> On loading the saved state those sizes were compared and failed to validate.
>>> KVM then aborts loading the saved state with that little helpful message.
>>>
>>> So you might want to check, if your case is similar to mine.
>>>
>>> I diagnosed that using gdb to single step kvm until I found
>>> hw/pci.c#get_pci_config_device() returning -EINVAL.
>>>
>>
>> Seems reasonable.  Doug, please verify to see if it's the same issue or
>> another one.
>>
>> Juan, how can we fix this?  It's clear that the option ROM size has to
>> be fixed and not change whenever the blob is updated.  This will fix it
>> for future releases.  But what to do about the ones in the field?
>
> This is not a problem upstream because we don't alter the ROMs.  If we
> did, we would keep the old ROMs around and set the romfile property in
> the compatible machine.
>
> This is what distros that are shipping ROMs outside of QEMU ought to
> do.  It's a bug to unconditionally change the ROMs (in a guest visible
> way) without adding compatibility support.
>
> Regards,
>
> Anthony Liguori
>

Anthony,

Gerd updated seabios on August 7th and before that on April 17. The
default VGA ROM size also changed in recent releases. There are no old
versions of the ROMs included once these updates are performed so a
user building a new version from source will hit this problem. Juan
Quintela even mentioned that he has been bit by this issue and had to
use gdb to track it down as did Philipp that responded earlier in the
thread. The patch is a simple fprintf() which would have saved at
least 3 users the effort of tracking down an issue with gdb. So I urge
you to reconsider.

Thanks.
-- 
Doug Goldstein