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

[Laszlo Ersek]

On 02/27/14 11:05, Chen Fan wrote:
> On Wed, 2014-02-26 at 13:31 +0100, Laszlo Ersek wrote:
> > On 02/26/14 09:43, Chen Fan wrote:
> > > 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?

I don't claim that EFI_MP_SERVICES_PROTOCOL would be useless for OVMF.
It's just that I personally don't see much use (but I could be wrong).
> > > > >    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.

You're right that I didn't consider suspend and resume separately. For
"raw" suspend you only need to advertise support (and a way) for the S3
state in ACPI, and we do that, indeed.

Resume is quite complex, and I can't imagine how it worked for you. I
reviewed the last patch this Tuesday and AFAICS Jordan hasn't pushed it yet.

Do we have the same thing in mind? If ACPI states S3 support/method,
then the OS will happily put the VM to S3 sleep. If you then wake the
machine but the firmware lacks code for S3 resume, the wakeup simply
decays to a reboot.
> > > > > 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?

edk2 implements most of the SMM related protocols (see PI spec volume
4), except the "lowest level" (hardware dependent) protocols related to
SMRAM / SMI. (EFI_SMM_ACCESS2_PROTOCOL and EFI_SMM_CONTROL2_PROTOCOL).

I think SMM belongs in the "unneeded" category.

Thanks,
Laszlo