[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.

> 
>>>
>>>>
>>>>>   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.
> 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