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

[Kevin O'Connor]

On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote:
> 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.

There is another complexity here - it's not always clear to me when a
group pulls a particular revision of SeaBIOS.  So, knowing who to
notify is harder.

> 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.

Agreed.  There has to be a balance here.

There are some USB drive booting fixes along with some ACPI and
MPTable changes in SeaBIOS post v1.6.3.1.  These changes are a bit
large though, so I'm not sure QEMU would be best served by pulling
them in if a release is pending.

That said, I'm glad to see users testing recent SeaBIOS revs as it
helps greatly with shaking out issues.  For example, had QEMU not
pulled a revision of SeaBIOS in August, there's a good chance this
particular bug would not have been found before the v1.6.3 release and
we might still have ended up in the same situation.

> 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.

If we can catch these types of things in test cases, that would be
great.  This particular bug had a complex set of triggers - it was in
SeaBIOS code specific to QEMU (so non-QEMU/KVM users wouldn't find
it), using QEMU's default Cirrus VGA driver masks the bug (it happens
to have PCI prefmem), and it was an off-by-one in low-level alignment
code (a code review wouldn't catch it).

-Kevin