Re: [Qemu-devel] KVM call agenda for 2013-05-28

From: Laszlo Ersek <lersek@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>,
	"Jordan Justen \(Intel address\)" <jordan.l.justen@intel.com>,
	seabios@seabios.org,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel]  KVM call agenda for 2013-05-28
Date: Thu, 30 May 2013 13:13:29 +0200	[thread overview]
Message-ID: <51A73459.2020407@redhat.com> (raw)
In-Reply-To: <1369905828.20691.50.camel@shinybook.infradead.org>

On 05/30/13 11:23, David Woodhouse wrote:
> On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>>
>>> Certainly an option, but that is a long-term project.
>>
>> Out of curiousity, are there other benefits to using coreboot as a core
>> firmware in QEMU?
>>
>> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
> 
> I like the idea of using Coreboot on the UEFI side — if the most
> actively used TianoCore platform is CorebootPkg instead of OvmfPkg, that
> makes it a lot easier for people using *real* hardware with Coreboot to
> use TianoCore.

Where is CorebootPkg available from?

> And it helps to dispel the stupid misconception in some quarters that
> Coreboot *competes* with UEFI and thus cannot possibly be supported
> because helping something that competes with UEFI would be bad.

I'm not sure who do you mean by "some quarters", but for some
distributions Coreboot would be yet another component (package) to
support, for no obvious benefit.

(Gerd said it better than I possibly could:
<http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705>.)

> 
>> Is there a payload we would ever plausibly use besides OVMF and
>> SeaBIOS?
> 
> For my part I want to get to the point where the default firmware
> shipped with qemu can be OVMF.

For some distributions this is a licensing question as well. See
"FatBinPkg/License.txt". (The same applies if you rebuild it from source
(FatPkgDev), based on "FatBinPkg/ReadMe.txt".)  For example Fedora can't
ship OVMF because of it.

If you implement a UEFI FAT driver based on Microsoft's official
specification, you're bound by the same restrictions on use and
redistribution.

If you implement a private UEFI FAT driver from scratch, or port a free
software FAT implementation (eg. the r/o one in grub or the r/w one in
mtools), you could still run into legal problems, I've been told.

If you rip out the FAT driver, then OVMF won't be UEFI compliant and no
installer media will boot on it.

Interestingly, Ubuntu has OVMF in "Universe"
<http://packages.ubuntu.com/raring/ovmf>. I think they missed the
FatBinPkg license (I would have missed it too, after all you have to
track down the licenses of every module included in the FDF file -- it
was Paolo who told me about it) and I believe they should actually ship
OVMF in Multiverse or Restricted
<https://help.ubuntu.com/community/Repositories/Ubuntu>.

> We have SeaBIOS-as-CSM working, which was
> one of the biggest barriers.

Agreed, and I could have never done that. Thanks for implementing it
with Kevin.

We need at least one out-of-tree edk2 patch for now (from you) but
apparently that's no problem.

> There are a few more things (like NV
> variable storage, in particular) that I need to fix before I can
> actually make that suggestion with a straight face though...

As far as I understand:
- Jordan is nearing completion of flash support on KVM,
- he also has WIP NvVar storage on top of qemu flash.

http://thread.gmane.org/gmane.comp.emulators.qemu/213690
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798

("Please coordinate" I guess :))

Laszlo

_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios