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: Carl-Daniel Hailfinger
Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0
Date: Mon, 05 Oct 2009 16:43:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081213 SUSE/1.1.14-1.1 SeaMonkey/1.1.14

On 05.10.2009 15:51, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> What about SeaBIOS + CSM (based on DUET)?
>
> That's not quite the same thing.
>
> In EFI, CSM is a specification that defines how to port a legacy BIOS
> such that it runs as basically an EFI module providing the old legacy
> BIOS interfaces that OSes support.  If you have a set of legacy option
> roms and efi modules, it defines how all of those things interact with
> each other to provide a consistent experience.

That's the design, but how do the implementations hold up? If we ignore
the "it's a spec" vs. "it's an industry standard not formalized
anywhere" distinction, DUET is an EFI compatibility layer/plugin/module
on top of a BIOS and a CSM is a BIOS compatibility layer/plugin/module
on top of EFI.
If DUET still uses the BIOS as claimed in the FAQ, is should be able to
reuse the handlers installed by classic option ROMs without problems.


> It's is not at all the same as just switching between EFI and BIOS. 
> It's much more tightly integrated than that.

OK, and how does a user specify "do not, under any circumstance, try to
boot with EFI" if a theoretically EFI capable OS (with broken EFI
support) is on disk? With current Qemu firmware, it just works (because
there is no EFI support). AFAICS EFI by default breaks such installations.


>> I can't speak for Patrick, but he probably was concerned about making
>> EFI the default with BIOS as fallback instead of the other way round.
>> Forcing any EFI capable (or semi-capable) OS to be booted with EFI
>> instead of leaving the choice in the hand of the user (NVRAM) or picking
>> the sane default (what almost all boards out there are doing) sounds
>> like a non-sustainable way for Qemu.  
>
> Why?  As long as it Just Works, I don't think it will ever even cross
> a users mind.

EFI support in enterprise Linux distributions is often not really good.
If the firmware tries EFI booting "just because it can", such
distributions will be booted with an almost untested path.


>>> We'll be stuck with legacy option roms for a long, long time.  But I
>>> also expect there will be a few devices out there that only provide
>>> EFI modules.
>>>     
>>
>> I expect that it will be some time before we see such devices (maybe
>> only at trade show demos if at all). It will start to get interesting
>> once such EFI modules have to interact with classic option ROMs.
>>   
>
> I think at the high end, we'll see these sooner than you think.

I just noticed that one big (>4000 nodes) Dell S1850 cluster deployment
(sort of mentioned as EFI example in older Intel literature) is
considering to drop EFI and use coreboot, maybe with SeaBIOS on top. The
journey ahead will be really interesting, regardless of where it ends.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





reply via email to

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