From: Juan Quintela <quintela@redhat.com>
To: Doug Goldstein <cardoe@gentoo.org>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
Avi Kivity <avi@redhat.com>, Philipp Hahn <hahn@univention.de>,
KVM mailing list <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: 1.1.1 -> 1.1.2 migrate /managedsave issue
Date: Tue, 06 Nov 2012 16:05:20 +0100 [thread overview]
Message-ID: <87y5iesrf3.fsf@trasno.org> (raw)
In-Reply-To: <CAFWqQMQz71DpoV8OQqW+t=MHTVYU3p+80PDa2=9jxO33-xEFWQ@mail.gmail.com> (Doug Goldstein's message of "Sun, 4 Nov 2012 23:41:20 -0600")
Doug Goldstein <cardoe@gentoo.org> wrote:
> On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>
>>> 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.
I hit this problem. But it was a bug, the problem was to detect it.
The problem was doing migration to an old version, we now "round" the
RAM amount to a multiple of 8k. If your old ram memory was mulitple of
4k, you get this prolbem with migration.
And it only prints "migration failed". Printing a message telling that:
memory size of %foo is %d and expected %d would have make error trivial
to found.
Later, Juan.
PD. Problem was really a bit more complex than this, this is a
simplification.
WARNING: multiple messages have this Message-ID (diff)
From: Juan Quintela <quintela@redhat.com>
To: Doug Goldstein <cardoe@gentoo.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
KVM mailing list <kvm@vger.kernel.org>,
Avi Kivity <avi@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Philipp Hahn <hahn@univention.de>
Subject: Re: [Qemu-devel] 1.1.1 -> 1.1.2 migrate /managedsave issue
Date: Tue, 06 Nov 2012 16:05:20 +0100 [thread overview]
Message-ID: <87y5iesrf3.fsf@trasno.org> (raw)
In-Reply-To: <CAFWqQMQz71DpoV8OQqW+t=MHTVYU3p+80PDa2=9jxO33-xEFWQ@mail.gmail.com> (Doug Goldstein's message of "Sun, 4 Nov 2012 23:41:20 -0600")
Doug Goldstein <cardoe@gentoo.org> wrote:
> On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>
>>> 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.
I hit this problem. But it was a bug, the problem was to detect it.
The problem was doing migration to an old version, we now "round" the
RAM amount to a multiple of 8k. If your old ram memory was mulitple of
4k, you get this prolbem with migration.
And it only prints "migration failed". Printing a message telling that:
memory size of %foo is %d and expected %d would have make error trivial
to found.
Later, Juan.
PD. Problem was really a bit more complex than this, this is a
simplification.
next prev parent reply other threads:[~2012-11-06 15:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 22:46 1.1.1 -> 1.1.2 migrate /managedsave issue Doug Goldstein
2012-10-22 7:04 ` Philipp Hahn
2012-10-22 11:23 ` Avi Kivity
2012-10-22 11:23 ` [Qemu-devel] " Avi Kivity
2012-10-23 20:38 ` Doug Goldstein
2012-10-23 20:38 ` [Qemu-devel] " Doug Goldstein
2012-10-24 6:59 ` Philipp Hahn
2012-10-24 6:59 ` [Qemu-devel] " Philipp Hahn
2012-10-29 6:22 ` Doug Goldstein
2012-10-29 6:22 ` [Qemu-devel] " Doug Goldstein
2012-11-04 21:51 ` Anthony Liguori
2012-11-04 21:51 ` [Qemu-devel] " Anthony Liguori
2012-11-05 5:41 ` Doug Goldstein
2012-11-05 5:41 ` [Qemu-devel] " Doug Goldstein
2012-11-06 15:05 ` Juan Quintela [this message]
2012-11-06 15:05 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5iesrf3.fsf@trasno.org \
--to=quintela@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=cardoe@gentoo.org \
--cc=hahn@univention.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.