[SeaBIOS] [edk2] investigate features differences between ovmf and seabios with QEMU
Chen Fan
chen.fan.fnst at cn.fujitsu.com
Wed Feb 26 10:00:20 CET 2014
Hi Andrew,
On Mon, 2014-02-24 at 21:28 -0800, Andrew Fish wrote:
> Chen,
>
>
> You also have to remember that BIOS requires a mixture of 16-bit
> assembly APIs and 1970s (and early 1980s) hardware devices to exist.
> These 1970’s hardware devices still exist in hardware (or are emulated
> in SMM) to support BIOS, option ROMs, and boot loader compatibility.
>
>
> Also the BIOS APIs have evolved over time, so at times there are
> multiple ways to do things, and the new way obsoletes the old way, but
> the old way still exists for backward compatibility. For example APM
> is 1992 technology, that was superseded by ACPI in 1996. So APM is
> only interesting if you are trying to boot an OS from the early to mid
> 1990’s.
>
I think the "CSM" feature can boot a legacy OS. also I don't care those
obsolete features.
>
> UEFI does not require a specific type of hardware to exist. An OS
> platform design guide probably specs out specific hardware that needs
> to exist, but is not really part of the UEFI spec. So an UEFI
> implementation can implements interrupts via APICs (or the ARM Generic
> Interrupt Contoller) and thus it does not need to support the 1970s
> 8259.
>
>
> Also in UEFI you don’t need the VM to emulate hardware. You can just
> build VM specific drivers that do VM calls. If you need to run
> pre-UEFI systems that is what the edk2 CSM is all about. It lets you
> boot in a legacy BIOS compatible way and that requires legacy BIOS
> code. This is where seabios (or some other codebase) would come into
> play.
>
Yes, I agree. but I want to know the feature differences between OVMF
and seabios. because if I hope to transition firmware from seabios to
ovmf with QEMU, I must know the changes for user in advance.
Thanks,
Chen
>
> Seabios and UEFI are doing different things in different ways so it
> has hard to make direct comparison.
>
>
> Thanks,
>
>
> Andrew Fish
>
> On Feb 24, 2014, at 3:59 AM, Laszlo Ersek <lersek at redhat.com> 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.
> >
> > Also, since we're talking "PC", I think we've never tried OVMF on
> > q35
> > machine types.
> >
> > > 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.
> >
> > > 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 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.
> >
> > > 28. suspend
> >
> > S3 is work in progress. It should make it into the tree soon.
> >
> > > 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.
> >
> > >
> > > 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".
> >
> > > 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.
> >
> > > 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.
> >
> > > 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.
> >
> > > 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.)
> >
> > 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'm sure I haven't been precise enough in this email, but it should
> > help
> > ignite the discussion :)
> >
> > Thanks
> > Laszlo
> >
> > ------------------------------------------------------------------------------
> > Flow-based real-time traffic analytics software. Cisco certified
> > tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
> > Analyzer
> > Customize your own dashboards, set traffic alerts and generate
> > reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
More information about the SeaBIOS
mailing list