On Wed, 15 Jun 2011, Peter Maydell wrote:
The underlying cause here is that QEMU's models are not tested in any formal way against a specification or against a test suite used for validating the hardware. The main test is "does it boot Linux?". So it's inevitable that new kernel features will be exercising essentially untested QEMU code, and breakage is quite likely.
CI will help to flag this kind of problem up sooner (and I have a blueprint for this cycle to work with the validation folks to expand the range of QEMU automated testing and benchmarking), but if we want to guarantee that QEMU and the kernel work together I think we really need to pretty much freeze the kernel two weeks before QEMU's release date, in order to have a fighting chance at catching and fixing problems.
I don't think it is reasonable to freeze the kernel for two weeks in a ~4 week cycle. Therefore we might have to consider simply not having the same release dates for all components. We could pipeline the dependencies instead of being all synchronous.
Nicolas