From: Anthony Liguori <anthony@codemonkey.ws>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: "seabios@seabios.org" <seabios@seabios.org>,
"Richard W.M. Jones" <rjones@redhat.com>,
qemu-devel@nongnu.org, Max Filippov <jcmvbkbc@gmail.com>,
Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>,
Amit Shah <amit.shah@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0
Date: Mon, 19 Dec 2011 12:02:59 -0600 [thread overview]
Message-ID: <4EEF7C53.6050800@codemonkey.ws> (raw)
In-Reply-To: <20111219174307.GB2558@redhat.com>
On 12/19/2011 11:43 AM, Daniel P. Berrange wrote:
> On Mon, Dec 19, 2011 at 11:34:13AM -0600, Anthony Liguori wrote:
>> On 12/19/2011 04:31 AM, Daniel P. Berrange wrote:
>>> Sigh, we really need to be better about updating SeaBIOS in QEMU before
>>> release. We had plenty of time to pull in a newer SeaBIOS before 1.0
>>> that would have fixed this :-(
>>
>> 1.6.3.1 was released on Nov 24th, which was actually after the soft
>> feature freeze. We could have pulled 1.6.3 which was Oct 4th but
>> updating the BIOS always results in some interesting things
>> happening so it's not something I like to do unless we have to.
>>
>> I'd rather have known that this functionality broken before that
>> commit event went in to begin with than allowing it to remain broken
>> until we happened to update past the bug.
>>
>>> We've had multiple releases now where
>>> functionality is broken due to QEMU shipping with an older SeaBIOS
>>> release than is available upstream.
>>
>> I think the real issue here is testing. -nodefconfig -nodefaults is
>> used by both libguestfs and libvirt but I'd wager to say that almost
>> noone tests it in QEMU.
>
> I had actually discovered& pointed out this flaw on qemu-devel back
> in September, and Kevin had the seabios fix by Oct
>
> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00029.html
>
> I hadn't raised it again, because I had mistakenly assumed QEMU
> will automatically pull in the newer SeaBios release before 1.0
> came out. I could have more aggresively bugged people on qemu-devel
> to update SeaBios, but given your point above about not wanting to
> rebase Seabios its not clear that would have helped sort this out
> before 1.0
We really need to update SeaBIOS whenever there is a bug that we know requires
an update. Things breakdown because of one or more of the following reasons:
1) User submits a patch to seabios@, Kevin applies it. But that doesn't
necessarily trigger anything happening in QEMU.
Ideally, the above mentioned user would submit a submodule update once (1) happens.
2) Kevin fixes something on his own or someone else changes something in the
broader SeaBIOS community. That may not even be visible in QEMU.
Syncing right before release isn't a good strategy either because that means
we're pulling in something that hasn't been tested extensively at the very tail
end of our release cycle.
I would like to point out that August -> October is a pretty long time period
for a regression like this to exist. I think that really indicates that the
primary problem is testing, not frequency of SeaBIOS updates.
Regards,
Anthony Liguori
> Regards,
> Daniel
next prev parent reply other threads:[~2011-12-19 18:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 13:11 [Qemu-devel] qemu.git hangs booting Linux after insmod virtio_blk.ko Richard W.M. Jones
2011-09-30 16:51 ` [Qemu-devel] git-bisect results (was: Re: qemu.git hangs booting Linux after insmod virtio_blk.ko) Richard W.M. Jones
2011-12-16 22:19 ` Richard W.M. Jones
2011-12-17 0:07 ` [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 (was: Re: git-bisect results (was: Re: qemu.git hangs booting Linux after insmod virtio_blk.ko)) Richard W.M. Jones
2011-12-17 0:26 ` Max Filippov
2011-12-17 0:53 ` Max Filippov
2011-12-17 1:44 ` [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 (was: Re: git-bisect results Anthony Liguori
2011-12-17 8:33 ` Richard W.M. Jones
2011-12-17 15:13 ` [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 Anthony Liguori
2011-12-17 15:22 ` Richard W.M. Jones
2011-12-17 15:22 ` Anthony Liguori
2011-12-17 15:25 ` Richard W.M. Jones
2011-12-17 16:24 ` Anthony Liguori
2011-12-17 16:35 ` Richard W.M. Jones
2011-12-17 16:49 ` Kevin O'Connor
2011-12-17 17:03 ` Anthony Liguori
2011-12-17 17:30 ` Richard W.M. Jones
2011-12-19 10:31 ` Daniel P. Berrange
2011-12-19 17:23 ` [Qemu-devel] [SeaBIOS] " Fred .
2011-12-19 17:26 ` Fred .
2011-12-19 17:34 ` [Qemu-devel] " Anthony Liguori
2011-12-19 17:43 ` Daniel P. Berrange
2011-12-19 18:02 ` Anthony Liguori [this message]
2011-12-19 19:04 ` Richard W.M. Jones
2011-12-19 19:16 ` Daniel P. Berrange
2011-12-19 19:40 ` Richard W.M. Jones
2011-12-19 19:42 ` Richard W.M. Jones
2011-12-19 19:44 ` Anthony Liguori
2011-12-19 19:19 ` Daniel P. Berrange
2011-12-19 19:26 ` Anthony Liguori
2011-12-20 3:38 ` Kevin O'Connor
2011-12-20 8:13 ` Gleb Natapov
2011-12-17 13:16 ` [Qemu-devel] insmod virtio-blk is broken in qemu 1.0 (was: Re: git-bisect results Richard W.M. Jones
2011-12-17 1:39 ` Anthony Liguori
2011-12-17 1:43 ` Anthony Liguori
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=4EEF7C53.6050800@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@redhat.com \
--cc=avi@redhat.com \
--cc=berrange@redhat.com \
--cc=jcmvbkbc@gmail.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=seabios@seabios.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).