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

[Chen Fan]

On Thu, 2014-02-27 at 12:29 +0100, Laszlo Ersek wrote:
> 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.
You're right, the suspend is also unstable. when I suspend a F18 guest,
it caused reboot occasionally.

> 
> > 
> >>>
> >>>>
> >>>>>   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.
I'm afraid "AHCI" could not be available within OVMF, I have add
"...AtaAtapiPassThru.inf" to both OvmfPkgX64.dsc and .fdf, then rebuild
OVMF.

I ran the same command line except DISK and BIOS file both Seabios and
OVMF:
qemu-system-x86_64 -smp 2 -drive
id=disk,file=/data/path/ovmf-test.img,if=none -device ahci,id=ahci0
-device ide-drive,bus=ahci0.0,drive=disk -m 2048 -enable-kvm
-bios ../edk2/Build/OvmfX64/DEBUG_GCC47/FV/OVMF.fd

OVMF can't find the disk. but can SEABIOS.


> >>
> >>>
> >>>>
> >>>>> 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.
> > 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.
Ok, thanks.

Best regards,
Chen


> 
> Thanks,
> Laszlo