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