qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreboot] [Qemu-devel] Release plan for 0.12.0


From: Jordan Justen
Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0
Date: Sat, 3 Oct 2009 15:40:38 -0700

On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer <address@hidden> wrote:
> Jordan Justen wrote:
>> On Sat, Oct 3, 2009 at 10:30, Peter Stuge <address@hidden> wrote:
>>
>>> Jordan Justen wrote:
>>>
>>>> Anyway, it sounds like a useful project might be to develop a UEFI
>>>> coreboot payload based on the tianocore.org code.
>>>>
>>> I believe it might have been done already.
>>>
>>> http://www.coreboot.org/File:Tianocoreboot.png
>>>
>>
>> That screenshot mentions DUET which is the tianocore.org UEFI emulator
>> that boots on top of a legacy BIOS.  But, it's unclear if it was just
>> DUET, or something based modified specifically for coreboot based on
>> DUET.
>>
>> I will not dispute that DUET might be a potential solution to achieve
>> UEFI compatibility for QEMU.  (I'm not sure, but I think DUET may not
>> be able to boot UEFI OS's at this time.)  However, we thought a
>> project such as OVMF was a more direct approach to achieve UEFI
>> compatibility for QEMU.
>>
>
> We have DUET running as a coreboot payload with a small coreboot
> specific PE payload loader.

Meaning you bring up a legacy BIOS compatible interface before
starting DUET?  DUET depends on a legacy BIOS.  My point is that a
tianocore.org based coreboot payload ought be able to do away with
this legacy BIOS dependency.

> DUET is, however, not an emulator, it is executing much of the same code
> as all other TianoCore based UEFI implementations.

According to the ReadMe.txt for our edk2 DuetPkg, DUET stands for
Developer's UEFI Emulation.  (Seems a bit of a stretch as an acronym.
:)  But, 'emulation' is a very squishy word at times, and this doesn't
imply that it can't accomplish a lot in terms of UEFI compatibility.

> It is possible to boot an OS just fine with DUET.
>
> Can you explain what you think would be more direct about OVMF than
> about DUET? As far as I understand it's another build target of EDK2 but
> besides that shares exactly the same design and even 99% of the code.

DUET expects that you boot a legacy BIOS, and then you load DUET off
the disk.  Once DUET is loaded, there is a (mostly) UEFI compatible
environment.

OVMF initializes the VM hardware and at the same time brings up the
(mostly) UEFI compatible environment.  This is basically the same
thing that would normally be done in most UEFI compatible systems.  To
me, this is a more direct approach to UEFI compatibility for QEMU.

Both DUET and OVMF have some slight issues with providing a fully
compatible UEFI variable interface.  But I know OVMF can still boot a
UEFI OS, and I thought DUET might have a problem in this area.  But, I
was fairly sure this could have been fixed in DUET, and it appears
that perhaps it has been.

Yes, DUET and OVMF likely share 90+% of the same code.

-Jordan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]