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

[Chen Fan]

Hi Laszlo,

   at first, thank you for your important feedback.

On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote:
> On 02/24/14 05:19, Chen Fan wrote:
> > Hi all,
> >     I'm a novice with OVMF, so please pardon me if I make any mistake.
> > 
> >     I have made a list about the feature differences between OVMF and
> > Seabios after investigation using QEMU. I simply use seabios source code
> > file name as the feature's name, then I made the following categorize
> > about OVMF supported/unsupported features. maybe there are some defects
> > at the list. and if this list miss some important features, please point
> > it out to me.
> >   I want to improve this list with you. so I'm welcome any comments and
> > suggestions.
> > 
> > Thanks,
> > Chen
> > 
> > -----------------------------------------------------------------------
> >   A: OVMF supports feature which seabios support it
> >      (This includes features which have similar bios)
> > -----------------------------------------------------------------------
> >   1. ata          2. blockcmd     3. dma         4. floppy
> >   5. pci          6. pic          7. ps2port     8. rtc
> >   9. timer        10. usb-ehci    11. usb-hid    12. usb-hub
> >   13. usb-msc     14. usb-uhci    
> 
> I'll call these, in a hand-waving manner, "basic PC peripheral support",
> and it's edk2 modules that support them, not directly OvmfPkg. IOW
> OvmfPkg pulls in / utilizes drivers from the edk2 tree unmodified to
> support these. For example, many drivers from under PcAtChipsetPkg/.
> 
> The end result is the same (ie. the OVMF.fd build you end up with
> supports them), but it's good to be clear about the scope when saying OVMF.
yes, the purpose of this list is to find out the feature support
differences between using -bios OVMF.fd and using default seabios rom
file with QEMU. in addition, I investigate this list is using 64 bit
OVMF-pure-efi.fd which RPM from <http://www.kraxel.org/repos/> and QEMU
using qemu-system-x86_64.

> Also, since we're talking "PC", I think we've never tried OVMF on q35
> machine types.
yes.

> 
> >   15. virtio-blk 16. virtio-pci
> >   17. virtio-ring 18. virtio-scsi
> 
> The virtio support we have could be a bit differently structured, but
> mostly "yes".
> 
> > 19. pci bus    20. VGA-cirrus
> >   21. ISA bridge  22. PCI IRQs    23. ISA        24. pci crs
> 
> Re ACPI (since you say PCI CRS): OVMF has some builtin tables, and the
> PCI CRS is built dynamically (kudos for guidance from Gerd et al). It
> works. When running on qemu machine types / qemu versions up to 1.6,
> this is the only ACPI stuff OVMF exports.
> 
> I plan to post an OVMF patch soonish (when qemu 1.7.1 is out) that will
> enable OVMF to download ACPI tables from qemu, benefiting from Michael
> Tsirkin's qemu work. Since SeaBIOS already does that, this should (a)
> synchronize ACPI between OVMF and SeaBIOS, (b) give some missing ACPI
> features to guest OSes running on OVMF "for free", like PCI hotplug and
> pvpanic.
I think that is good news. maybe cpu hotplug will be supported too by
that time.

> 
> >   25. mtrr
> 
> Yes, although as I gather this is mostly cosmetic in KVM guests.
> 
> > 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.

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

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

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

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

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

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

> 
> I'm sure I haven't been precise enough in this email, but it should help
> ignite the discussion :)
Thanks, you have done me a great favor.

Chen


> 
> Thanks
> Laszlo