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 <ler...@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@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
