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