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

From: Anthony Liguori <anthony@codemonkey.ws>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	qemu-devel@nongnu.org, Max Filippov <jcmvbkbc@gmail.com>,
	Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>,
	Amit Shah <amit.shah@redhat.com>,
	jforbes@fedoraproject.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0
Date: Mon, 19 Dec 2011 13:44:33 -0600	[thread overview]
Message-ID: <4EEF9421.40708@codemonkey.ws> (raw)
In-Reply-To: <20111219194005.GE2909@amd.home.annexia.org>

On 12/19/2011 01:40 PM, Richard W.M. Jones wrote:
> On Mon, Dec 19, 2011 at 07:16:02PM +0000, Daniel P. Berrange wrote:
>> On Mon, Dec 19, 2011 at 07:04:54PM +0000, Richard W.M. Jones wrote:
>>> On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote:
>>>> 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.
>>>
>>> Fair point.
>>>
>>> My understanding is we're going to switch to having qemu.git in Fedora
>>> Rawhide, which means that libguestfs will always be testing the
>>> 'perfect storm' of qemu + kernel + glibc from git (once glibc get
>>> their act together anyhow, just qemu + kernel at first).
>>>
>>> We usually do a build and a comprehensive test at least once a week,
>>> often a few times a week, so we would have picked this up much sooner.
>>
>> That wouldn't actually catch this problem, because when we build
>> QEMU in Fedora, we never use the SeaBIOS that QEMU includes in
>> GIT. Fedora always ships the newest SeaBIOS release available
>> from upstream, regardless of what QEMU includes.
>
> Ah yes indeed, I forgot about this.
>
> Nevertheless, it'll at least improve other aspects of our
> qemu testing :-)
>
> In reply to Anthony: the reason Fedora does this is because
> binary blobs aren't permitted, no matter what the origin.  We
> have to build SeaBIOS from source, and the choice is made to
> build from the upstream SeaBIOS source, not from the source
> release indirectly pointed to by qemu.

FWIW, we ship SeaBIOS source directly in our release tarballs.  There's nothing 
indirect about it.

Fedora could have a seabios-qemu RPM that was built from the qemu SRPM.  Since 
it ultimately is going to live in /usr/share/qemu, that seems like a nicer thing 
to do AFAICT.

You could have an alternatives mechanism if people really wanted to use upstream 
SeaBIOS...

Regards,

Anthony Liguori

>
> Rich.
>