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 15. virtio-blk 16. virtio-pci 17. virtio-ring 18. virtio-scsi 19. pci bus 20. VGA-cirrus 21. ISA bridge 22. PCI IRQs 23. ISA 24. pci crs 25. mtrr 26. smbios 27. smp 28. suspend 29. block 30. boot 31. cdrom 32. output 33. resume 34. serial 35. usb 36. pciint 37. optionroms 38. xen 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
P.S: the values in parentheses represents the seabios feature.
--------------------------------------------------------------------- B: OVMF does not support features which seabios support it --------------------------------------------------------------------- 53. ahci 54. usb-ohci 55. esp-scsi 56. lsi-scsi 57. magasas 58. usb-uas 59. usb-xhci 60. cpu-hotplug 61. acpi-dbug 62. VGA-std 63. PIIX4 PM 64. pci-hotplug 65. GPE 66. hpet 67. q35 68. pvpanic 69. processor table 70. smm 71. pnp bios 72. gdb
--------------------------------------------------------------------- C: OVMF does not need to support feature which seabios support (due to UEFI's spec/implementation) --------------------------------------------------------------------- 73. ramdisk 74. lzma decoder 75. biostable 76. coreboot 77. shadow 78. apm
D: OVMF supports feature which is required by UEFI spec 79. CSM 80. GPT 81. secureboot
--------------------------------------------------------------------- E: OVMF does not support feature which is required by UEFI spec --------------------------------------------------------------------- 82. i18n
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 andSeabios 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)
- ata 2. blockcmd 3. dma 4. floppy
- pci 6. pic 7. ps2port 8. rtc
- timer 10. usb-ehci 11. usb-hid 12. usb-hub
- 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.
- virtio-blk 16. virtio-pci
- virtio-ring 18. virtio-scsi
The virtio support we have could be a bit differently structured, but mostly "yes".
- pci bus 20. VGA-cirrus
- 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.
- mtrr
Yes, although as I gather this is mostly cosmetic in KVM guests.
- 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.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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".
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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.
- GPE 66. hpet 67. q35 68. pvpanic
- 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.
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
- 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.
- 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.
- 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
- 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
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.
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.
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@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)
- ata 2. blockcmd 3. dma 4. floppy
- pci 6. pic 7. ps2port 8. rtc
- timer 10. usb-ehci 11. usb-hid 12. usb-hub
- 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.
- virtio-blk 16. virtio-pci
- virtio-ring 18. virtio-scsi
The virtio support we have could be a bit differently structured, but mostly "yes".
- pci bus 20. VGA-cirrus
- 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.
- mtrr
Yes, although as I gather this is mostly cosmetic in KVM guests.
- 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.
- 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. suspendS3 is work in progress. It should make it into the tree soon.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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".
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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.
- GPE 66. hpet 67. q35 68. pvpanic
- 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 biosNot sure what to make of this. I'll have a few words about CSM.
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
- 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.
- 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.
- 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
- 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.cl... _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
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 andSeabios 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)
- ata 2. blockcmd 3. dma 4. floppy
- pci 6. pic 7. ps2port 8. rtc
- timer 10. usb-ehci 11. usb-hid 12. usb-hub
- 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.
- virtio-blk 16. virtio-pci
- virtio-ring 18. virtio-scsi
The virtio support we have could be a bit differently structured, but mostly "yes".
- pci bus 20. VGA-cirrus
- 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.
- mtrr
Yes, although as I gather this is mostly cosmetic in KVM guests.
- 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. smpNot 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. suspendS3 is work in progress. It should make it into the tree soon.
ok, Thanks.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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?
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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.
- GPE 66. hpet 67. q35 68. pvpanic
- 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 biosNot 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?
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
oh I see.
- 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.
- 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.
- 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
- 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
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@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)
- ata 2. blockcmd 3. dma 4. floppy
- pci 6. pic 7. ps2port 8. rtc
- timer 10. usb-ehci 11. usb-hid 12. usb-hub
- 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.
- virtio-blk 16. virtio-pci
- virtio-ring 18. virtio-scsi
The virtio support we have could be a bit differently structured, but mostly "yes".
- pci bus 20. VGA-cirrus
- 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.
- mtrr
Yes, although as I gather this is mostly cosmetic in KVM guests.
- 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.
- 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. suspendS3 is work in progress. It should make it into the tree soon.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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".
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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.
- GPE 66. hpet 67. q35 68. pvpanic
- 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 biosNot sure what to make of this. I'll have a few words about CSM.
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
- 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.
- 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.
- 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
- 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.cl... _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On 02/26/14 09:43, Chen Fan wrote:
On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote:
On 02/24/14 05:19, Chen Fan wrote:
- 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.
In master, you see this:
# SMBIOS Support # MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
The first driver provides the EFI_SMBIOS_PROTOCOL implementation that we need to install and massage SMBIOS tables.
The second driver installs some tables, using the first driver. Only tables from Xen are covered.
When I referred to "the SMBIOS integration that you might have become accustomed to between qemu and SeaBIOS", I meant the Type0 and Type1 default tables in SMBIOS, and the fw_cfg facilities that allow qemu to dynamically export both full tables (for any type) and field-level patches (for some well-known table types) to SeaBIOS.
The patches that support this in OVMF are not in master. (But you can test them in Gerd's RPM.)
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. smpNot 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.
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.
28. suspendS3 is work in progress. It should make it into the tree soon.
ok, Thanks.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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.
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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
- GPE 66. hpet 67. q35 68. pvpanic
- 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 biosNot 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?
CSM and/or old-style option roms are certainly not a requirement for UEFI.
PCI cards can provide UEFI drivers in their ROM BARs (and they are loaded / started with "highest priority" as far as I remember). In edk2 in general, it is controllable at build time whether you require, in secure boot mode, such oprom drivers to be signed. Search for "PcdOptionRomImageVerificationPolicy".
PCI cards can also provide combined BIOS/UEFI option ROMs. For example, the
pc-bios/efi-e1000.rom pc-bios/efi-eepro100.rom pc-bios/efi-ne2k_pci.rom pc-bios/efi-pcnet.rom pc-bios/efi-rtl8139.rom pc-bios/efi-virtio.rom
files in the qemu git tree are such (combined) NIC oproms, built from the iPXE project. If you install a reasonably fresh qemu from source, and start it with a virtio-net controller:
-device virtio-net-pci
then qemu will per default load the "pc-bios/efi-virtio.rom" file and expose it in the ROM bar. Then edk2/OVMF will load/start the UEFI build of the iPXE driver from that combined image, and you can PXE boot with it.
Alternatively, if you specify
-device virtio-net-pci,romfile=
then qemu won't fill in the ROM bar, and OVMF will fall back to the built-in VirtioNetDxe driver.
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
oh I see.
- 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.
- 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?
Correct. You can't do that with upstream OVMF for the time being.
You can try with Gerd's RPM (the CSM build of the FD file), it includes some version of the support patches.
In any case, I *strongly* believe that if you want to virtualize a legacy OS, then just use SeaBIOS. Switching firmware on-demand is very easy in virtualization, there's no reason not to pick SeaBIOS for legacy OSes, and pure OVMF for UEFI OSes. The CSM stuff is black magic, we've had very hard/bad bugs in relation to it. There's no reason to pull in extra complexity just so you can always boot an OVMF firmware image.
(I'll admit that this is my personal opinion. As far as I remember, Gerd agrees, for example, and David disagrees.)
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.
- 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
- 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.
Correct. The infrastructure is there, but for further languages translations of HII strings, and optionally new HII font packages, will be necessary.
Cheers! Laszlo
On Wed, 2014-02-26 at 13:31 +0100, Laszlo Ersek wrote:
On 02/26/14 09:43, Chen Fan wrote:
On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote:
On 02/24/14 05:19, Chen Fan wrote:
- 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.
In master, you see this:
# SMBIOS Support # MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
The first driver provides the EFI_SMBIOS_PROTOCOL implementation that we need to install and massage SMBIOS tables.
The second driver installs some tables, using the first driver. Only tables from Xen are covered.
When I referred to "the SMBIOS integration that you might have become accustomed to between qemu and SeaBIOS", I meant the Type0 and Type1 default tables in SMBIOS, and the fw_cfg facilities that allow qemu to dynamically export both full tables (for any type) and field-level patches (for some well-known table types) to SeaBIOS.
The patches that support this in OVMF are not in master. (But you can test them in Gerd's RPM.)
I had test it and the result as you said.
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. smpNot 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.
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?
28. suspendS3 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.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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.
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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
- GPE 66. hpet 67. q35 68. pvpanic
- 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?
71. pnp biosNot 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?
CSM and/or old-style option roms are certainly not a requirement for UEFI.
PCI cards can provide UEFI drivers in their ROM BARs (and they are loaded / started with "highest priority" as far as I remember). In edk2 in general, it is controllable at build time whether you require, in secure boot mode, such oprom drivers to be signed. Search for "PcdOptionRomImageVerificationPolicy".
PCI cards can also provide combined BIOS/UEFI option ROMs. For example, the
pc-bios/efi-e1000.rom pc-bios/efi-eepro100.rom pc-bios/efi-ne2k_pci.rom pc-bios/efi-pcnet.rom pc-bios/efi-rtl8139.rom pc-bios/efi-virtio.rom
files in the qemu git tree are such (combined) NIC oproms, built from the iPXE project. If you install a reasonably fresh qemu from source, and start it with a virtio-net controller:
-device virtio-net-pci
then qemu will per default load the "pc-bios/efi-virtio.rom" file and expose it in the ROM bar. Then edk2/OVMF will load/start the UEFI build of the iPXE driver from that combined image, and you can PXE boot with it.
Alternatively, if you specify
-device virtio-net-pci,romfile=
then qemu won't fill in the ROM bar, and OVMF will fall back to the built-in VirtioNetDxe driver.
- 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)
- ramdisk 74. lzma decoder
Actually edk2 uses LZMA quite a bit. Most of the firmware image is compressed.
oh I see.
- 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.
- 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?
Correct. You can't do that with upstream OVMF for the time being.
You can try with Gerd's RPM (the CSM build of the FD file), it includes some version of the support patches.
In any case, I *strongly* believe that if you want to virtualize a legacy OS, then just use SeaBIOS. Switching firmware on-demand is very easy in virtualization, there's no reason not to pick SeaBIOS for legacy OSes, and pure OVMF for UEFI OSes. The CSM stuff is black magic, we've had very hard/bad bugs in relation to it. There's no reason to pull in extra complexity just so you can always boot an OVMF firmware image.
(I'll admit that this is my personal opinion. As far as I remember, Gerd agrees, for example, and David disagrees.)
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.
- 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
- 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.
Correct. The infrastructure is there, but for further languages translations of HII strings, and optionally new HII font packages, will be necessary.
Regards, Chen
Cheers! Laszlo
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. suspendS3 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.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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.
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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
- GPE 66. hpet 67. q35 68. pvpanic
- 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
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. suspendS3 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.
- 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.
- cdrom 32. output
- resume 34. serial 35. usb 36. pciint
- optionroms 38. xen
The Xen community certainly cares about OVMF. For details you'll have to talk to them.
- 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
- 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.
- usb-ohci 55. esp-scsi 56. lsi-scsi
- magasas
These look like various SCSI HBA's. edk2 probably has no drivers, indeed. I'm not convinced we need to support them.
- usb-uas 59. usb-xhci
I think the same applies to XHCI as to AHCI, see MdeModulePkg/Bus/Pci/XhciDxe.
- cpu-hotplug
- 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
- GPE 66. hpet 67. q35 68. pvpanic
- 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
-
Andrew Fish -
Chen Fan -
Laszlo Ersek