[Top][All Lists]

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

Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0

From: Anthony Liguori
Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0
Date: Mon, 19 Dec 2011 12:02:59 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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 :-( 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


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) 

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.


Anthony Liguori


reply via email to

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