[SeaBIOS] [edk2] investigate features differences between ovmf and seabios with QEMU
Laszlo Ersek
lersek at redhat.com
Wed Feb 26 13:31:46 CET 2014
On 02/26/14 09:43, Chen Fan wrote:
> On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote:
>> On 02/24/14 05:19, Chen Fan wrote:
>>> 26. smbios
>>
>> The SMBIOS integration that you might have become accustomed to between
>> qemu and SeaBIOS is not upstream OVMF.
> I'm confused, I have seen the "SMBIOS supported" sample in
> OvmfPkgX64.dsc file.
In master, you see this:
# SMBIOS Support
#
MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
The first driver provides the EFI_SMBIOS_PROTOCOL implementation that we
need to install and massage SMBIOS tables.
The second driver installs some tables, using the first driver. Only
tables from Xen are covered.
When I referred to "the SMBIOS integration that you might have become
accustomed to between qemu and SeaBIOS", I meant the Type0 and Type1
default tables in SMBIOS, and the fw_cfg facilities that allow qemu to
dynamically export both full tables (for any type) and field-level
patches (for some well-known table types) to SeaBIOS.
The patches that support this in OVMF are not in master. (But you can
test them in Gerd's RPM.)
>
>>
>> I posted patches for that, I run them every day, and Gerd's RPMs
>> <http://www.kraxel.org/repos/> and IIRC Paolo's Copr builds
>> <http://copr-be.cloud.fedoraproject.org/results/bonzini/ovmf/> include
>> them. They are not in the upstream tree because Jordan and myself
>> disagree on how SMBIOS should be worked out in OVMF.
>>
>> If I recall correctly, Jordan's point was to factor out SMBIOS code from
>> another client package (EmulatorPkg if I remember?...), librarize it in
>> a central edk2 location (like MdeModulePkg), and use this library /
>> integrate it with qemu in OVMF. My patches add custom / independent code
>> to SMBIOS.
>>
>> Jordan's suggestion would involve a lot of work, and modifying the
>> Mde*Pkg directories (aside from obvious small fixes) is very hard from a
>> project management POV. Spending cycles on this is not economic for me,
>> especially after having implemented the custom patches, so I'm not doing it.
>>
>>> 27. smp
>>
>> Not sure what this covers. Jordan has out-of-tree WIP for MP services,
>> and it's possible someone will help with it in the near future.
> what features will be provided by MP services? the smp feature includes
> detect and initialize the all CPUs in SeaBios.
Basically, the same. See
13.3 MP Services Protocol Overview
and
13.4 MP Services Protocol
in
<http://www.uefi.org/specs/download>
VOLUME 2: Platform Initialization Specification
Driver Execution Environment Core Interface
Honestly, I don't know what it is good for, to bring up APs before the
OS starts. OVMF doesn't do that right now (it doesn't implement
EFI_MP_SERVICES_PROTOCOL), and both Linux and Windows guests can start
and use all processors just the same. We get the number of qemu's VCPUs
via fw_cfg, and expose that in the MADT. 13.3 says in one spot:
MP Services Protocol may be consumed by ACPI module. The ACPI
module may use this protocol to retrieve data that are needed for
an MP platform and report them to OS.
We use fw_cfg as source for this information, not
EFI_MP_SERVICES_PROTOCOL. (Note that EFI_MP_SERVICES_PROTOCOL is not
part of UEFI, it belongs to PI.)
Multi-threaded execution (on multiple CPUs) is not supported in UEFI
anyway. You can approximate it with an illusion, by using timers, but it
won't "parallelize" to several CPUs.
In another spot, 13.3 says
MP Services Protocol may also be used to program and configure
processors, such as MTRR synchronization for memory space
attributes setting in DXE Services.
First, as I've been informed, MTRR is more like decoration than
something with an actual effect under KVM. Second, on some (physical)
Intel processor models, MTRR configuration *must* indeed happen in
strict lock-step, on all processors at once. However, OSes already do
this. By virtue of not starting the APs, we push the responsibility of
MTRR setup to the guest OS.
>
>>
>>> 28. suspend
>>
>> S3 is work in progress. It should make it into the tree soon.
> ok, Thanks.
>
>>
>>> 29. block 30. boot
>>
>> OVMF supports qemu boot order specs, but the huge conceptual difference
>> between UEFI boot options and the traditional BIOS boot options / the
>> OpenFirmware expressive power keeps us revising details and fixing bugs.
>>
>>> 31. cdrom 32. output
>>> 33. resume 34. serial 35. usb 36. pciint
>>> 37. optionroms 38. xen
>>
>> The Xen community certainly cares about OVMF. For details you'll have to
>> talk to them.
>>
>>> 39. vgahooks 40. PCI I/O protcol(pci
>>> bios)
>>> 41. DSDT table 42. SEC (post) 43. MADT table 44. font
>>> 45. mouse 46. disk 47. kbd 48. clock
>>> 49. memmap 50. Memory Allocation Services (pmm)
>>> 51. System table (biosvar) 52. FW_CFG
>>
>> "Yes", in general. I'll just single out "font", which to me implies HII
>> in UEFI / edk2, and it's a beast.
> I do not find where to change the font in OVMF. maybe we can categorize
> "font" to B: OVMF does not support for the moment.
In that sense, right, you can't change the font. But edk2 includes the
infrastructure that would let you add a new font package.
Of course I never tried to do that. I looked now an found two clients
that install fonts:
(1) RegisterFontPackage() in
"MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c".
The glyph data comes from "gUsStdNarrowGlyphData", in
"MdeModulePkg/Universal/Console/GraphicsConsoleDxe/LaffStd.c".
(2) ExportFonts() in
"IntelFrameworkModulePkg/Universal/BdsDxe/Language.c". The glyph-data is
present in the same file ("mFontBin").
>>
>>>
>>> P.S:
>>> the values in parentheses represents the seabios feature.
>>>
>>> ---------------------------------------------------------------------
>>> B: OVMF does not support features which seabios support it
>>> ---------------------------------------------------------------------
>>> 53. ahci
>>
>> Hmm. I think edk2 in general does support AHCI
>> (seeMdeModulePkg/Bus/Ata/AtaAtapiPassThru), we just don't include it. I
>> think we should have a good use case for drivers / features; more than
>> just "feature parity with SeaBIOS".
> I want to figure out which features are supported in OVMF. I don't care
> edk2 features. I know edk2 may include these features. in other words,
> can we use it in OVMF if we just include this feature came from edk2?
You can only tell if you try it :) The INF file in that directory does say:
AtaAtapiPassThru driver to provide native IDE/AHCI mode support
So, you could
- add "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf" to
both OvmfPkgX64.dsc and .fdf (for the syntax, check out how the virtio
drivers, for example "OvmfPkg/VirtioBlkDxe/VirtioBlk.inf", are included),
- rebuild OVMF, and
- boot it on a qemu where you enable AHCI on the command line.
>
>>
>>> 54. usb-ohci 55. esp-scsi 56. lsi-scsi
>>> 57. magasas
>>
>> These look like various SCSI HBA's. edk2 probably has no drivers,
>> indeed. I'm not convinced we need to support them.
>
>>
>>> 58. usb-uas 59. usb-xhci
>>
>> I think the same applies to XHCI as to AHCI, see
>> MdeModulePkg/Bus/Pci/XhciDxe.
>>
>>> 60. cpu-hotplug
>>> 61. acpi-dbug 62. VGA-std 63. PIIX4 PM 64. pci-hotplug
>>
>> I'm not sure if CPU and/or PCI hotplug is very useful during the
>> firmware's lifetime (and I don't know if the above SeaBIOS files imply
>> such support). If you mean the ACPI dependencies, they should come "for
>> free" once we have the ACPI download patch in place.
> if OVMF could download ACPI table from qemu. I think CPU/PCI hotplug
> will be supported.
I did test PCI hot-plug / hot-unplug once, in a Windows guest, with the
ACPI download patch in place. I used a virtio-blk device as victim:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3917/focus=4891
>
>>
>>> 65. GPE 66. hpet 67. q35 68. pvpanic
>>> 69. processor table 70. smm
>>
>> No SMM in OVMF; KVM doesn't support it (last I heard). edk2 has
>> extensive support for SMM otherwise.
>
>>
>>> 71. pnp bios
>>
>> Not sure what to make of this. I'll have a few words about CSM.
>
> Does not pnp bios required in OVMF/EFI? or another way to do the same?
CSM and/or old-style option roms are certainly not a requirement for UEFI.
PCI cards can provide UEFI drivers in their ROM BARs (and they are
loaded / started with "highest priority" as far as I remember). In edk2
in general, it is controllable at build time whether you require, in
secure boot mode, such oprom drivers to be signed. Search for
"PcdOptionRomImageVerificationPolicy".
PCI cards can also provide combined BIOS/UEFI option ROMs. For example, the
pc-bios/efi-e1000.rom
pc-bios/efi-eepro100.rom
pc-bios/efi-ne2k_pci.rom
pc-bios/efi-pcnet.rom
pc-bios/efi-rtl8139.rom
pc-bios/efi-virtio.rom
files in the qemu git tree are such (combined) NIC oproms, built from
the iPXE project. If you install a reasonably fresh qemu from source,
and start it with a virtio-net controller:
-device virtio-net-pci
then qemu will per default load the "pc-bios/efi-virtio.rom" file and
expose it in the ROM bar. Then edk2/OVMF will load/start the UEFI build
of the iPXE driver from that combined image, and you can PXE boot with it.
Alternatively, if you specify
-device virtio-net-pci,romfile=
then qemu won't fill in the ROM bar, and OVMF will fall back to the
built-in VirtioNetDxe driver.
>
>>
>>> 72. gdb
>>
>> Source level debugging of OVMF is not solved / supported, at leat not by
>> tools in the upstream tree. There have been elaborate and working hacks
>> but they've gone stale. For me personally debug messages beat anything
>> and everything and lack of gdb is a non-issue.
>>
>>>
>>> ---------------------------------------------------------------------
>>> C: OVMF does not need to support feature which seabios support
>>> (due to UEFI's spec/implementation)
>>> ---------------------------------------------------------------------
>>> 73. ramdisk 74. lzma decoder
>>
>> Actually edk2 uses LZMA quite a bit. Most of the firmware image is
>> compressed.
> oh I see.
>>
>>> 75. biostable 76. coreboot
>>
>> There are efforts to support coreboot and OVMF in combination (google
>> CorebootPkg). I have no clue of the scope, and it's not upstream.
>>
>>> 77. shadow 78. apm
>>>
>>> D: OVMF supports feature which is required by UEFI spec
>>> 79. CSM
>>
>> David Woodhouse and Kevin O'Connor have done huge work to make this
>> work, covering both SeaBIOS and edk2/OVMF.
>>
>> The edk2 patches are not in-tree yet. Actually the precise set of the
>> edk2 patches to include is not fully "agreed upon" yet. In my local tree
>> I carry the two critical patches from David on a topic branch. Gerd's
>> RPMs also provide a pure-UEFI *and* a CSM build of OVMF. (The flavor you
>> want must be specified at build time.)
> oh, this mean the patches of OVMF is not fully applied. in other words,
> we can't use OVMF with CSM to start legacy OS yet. right?
Correct. You can't do that with upstream OVMF for the time being.
You can try with Gerd's RPM (the CSM build of the FD file), it includes
some version of the support patches.
In any case, I *strongly* believe that if you want to virtualize a
legacy OS, then just use SeaBIOS. Switching firmware on-demand is very
easy in virtualization, there's no reason not to pick SeaBIOS for legacy
OSes, and pure OVMF for UEFI OSes. The CSM stuff is black magic, we've
had very hard/bad bugs in relation to it. There's no reason to pull in
extra complexity just so you can always boot an OVMF firmware image.
(I'll admit that this is my personal opinion. As far as I remember, Gerd
agrees, for example, and David disagrees.)
>
>>
>> David even managed to change the CSM specification -- additional fields
>> were needed between edk2 and SeaBIOS. v0.98 (IIRC) of the spec is
>> supposed to describe these too, but I'm not sure about the release
>> status of this version.
>>
>>> 80. GPT 81. secureboot
>>
>> Yes. (Side note: secure boot is per-spec incompatible with CSM.)
>>
>>>
>>> ---------------------------------------------------------------------
>>> E: OVMF does not support feature which is required by UEFI spec
>>> ---------------------------------------------------------------------
>>> 82. i18n
>>
>> This is incorrect I'd think (it depends on the scope you have in mind of
>> course): edk2 has super-extensive support for HII, which covers fonts,
>> languages etc.
> I just mean that currently there were only two languages: English and
> French, and i18n should have more language support.
Correct. The infrastructure is there, but for further languages
translations of HII strings, and optionally new HII font packages, will
be necessary.
Cheers!
Laszlo
More information about the SeaBIOS
mailing list