Re: [SeaBIOS] [edk2] investigate features differences between ovmf and seabios with QEMU

[Chen Fan]

On Wed, 2014-02-26 at 13:31 +0100, Laszlo Ersek wrote:
> 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:
> > > > 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 had test it and the result as you said.
> > > 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.

OK, maybe we can set "smp" to C: OVMF does not need to support feature,
right?
> > > >    28. suspend
> > >
> > > S3 is work in progress. It should make it into the tree soon.
> >
> > ok, Thanks.

sorry, I don't known why when you said that "S3 is work in progress",
but I had test it with OVMF.fd got from master tree, it worked fine.
"resume" is the same.
> > > > 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.
> > > > cdrom      32. output
> > > > resume      34. serial      35. usb        36. pciint
> > > > optionroms  38. xen
> > >
> > > The Xen community certainly cares about OVMF. For details you'll have to
> > > talk to them.
> > > > 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
> > > > 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.
> > > > usb-ohci    55. esp-scsi   56. lsi-scsi
> > > > magasas
> > >
> > > These look like various SCSI HBA's. edk2 probably has no drivers,
> > > indeed. I'm not convinced we need to support them.
> > > > usb-uas     59. usb-xhci
> > >
> > > I think the same applies to XHCI as to AHCI, see
> > > MdeModulePkg/Bus/Pci/XhciDxe.
> > > > cpu-hotplug
> > > > 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
> > > > GPE         66. hpet        67. q35        68. pvpanic
> > > > processor table             70. smm
> > >
> > > No SMM in OVMF; KVM doesn't support it (last I heard). edk2 has
> > > extensive support for SMM otherwise.

how did edk2 to support SMM?
> > > >    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.
> > > > 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)
> > > > ramdisk    74. lzma decoder
> > >
> > > Actually edk2 uses LZMA quite a bit. Most of the firmware image is
> > > compressed.
> >
> > oh I see.
> > > > 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.
> > > > 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.
> > > > 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
> > > > 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.

Regards,
Chen
> Cheers!
> Laszlo