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:
>
> >>> 26. smbios
> >>
> >> The SMBIOS integration that you might have become accustomed to between
> >> qemu and SeaBIOS is not upstream OVMF.
> > I'm confused, I have seen the "SMBIOS supported" sample in
> > OvmfPkgX64.dsc file.
>
> 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. smp
> >>
> >> Not sure what this covers. Jordan has out-of-tree WIP for MP services,
> >> and it's possible someone will help with it in the near future.
> > what features will be provided by MP services? the smp feature includes
> > detect and initialize the all CPUs in SeaBios.
>
> 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. suspend
> >>
> >> S3 is work in progress. It should make it into the tree soon.
> > ok, Thanks.
sorry, I don't known why when you said that "S3 is work in progress",
but I had test it with OVMF.fd got from master tree, it worked fine.
"resume" is the same.
> >
> >>
> >>> 29. block 30. boot
> >>
> >> OVMF supports qemu boot order specs, but the huge conceptual difference
> >> between UEFI boot options and the traditional BIOS boot options / the
> >> OpenFirmware expressive power keeps us revising details and fixing bugs.
> >>
> >>> 31. cdrom 32. output
> >>> 33. resume 34. serial 35. usb 36. pciint
> >>> 37. optionroms 38. xen
> >>
> >> The Xen community certainly cares about OVMF. For details you'll have to
> >> talk to them.
> >>
> >>> 39. vgahooks 40. PCI I/O protcol(pci
> >>> bios)
> >>> 41. DSDT table 42. SEC (post) 43. MADT table 44. font
> >>> 45. mouse 46. disk 47. kbd 48. clock
> >>> 49. memmap 50. Memory Allocation Services (pmm)
> >>> 51. System table (biosvar) 52. FW_CFG
> >>
> >> "Yes", in general. I'll just single out "font", which to me implies HII
> >> in UEFI / edk2, and it's a beast.
> > I do not find where to change the font in OVMF. maybe we can categorize
> > "font" to B: OVMF does not support for the moment.
>
> In that sense, right, you can't change the font. But edk2 includes the
> infrastructure that would let you add a new font package.
>
> Of course I never tried to do that. I looked now an found two clients
> that install fonts:
>
> (1) RegisterFontPackage() in
> "MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c".
>
> The glyph data comes from "gUsStdNarrowGlyphData", in
> "MdeModulePkg/Universal/Console/GraphicsConsoleDxe/LaffStd.c".
>
> (2) ExportFonts() in
> "IntelFrameworkModulePkg/Universal/BdsDxe/Language.c". The glyph-data is
> present in the same file ("mFontBin").
>
>
> >>
> >>>
> >>> P.S:
> >>> the values in parentheses represents the seabios feature.
> >>>
> >>> ---------------------------------------------------------------------
> >>> B: OVMF does not support features which seabios support it
> >>> ---------------------------------------------------------------------
> >>> 53. ahci
> >>
> >> Hmm. I think edk2 in general does support AHCI
> >> (seeMdeModulePkg/Bus/Ata/AtaAtapiPassThru), we just don't include it. I
> >> think we should have a good use case for drivers / features; more than
> >> just "feature parity with SeaBIOS".
> > I want to figure out which features are supported in OVMF. I don't care
> > edk2 features. I know edk2 may include these features. in other words,
> > can we use it in OVMF if we just include this feature came from edk2?
>
> You can only tell if you try it :) The INF file in that directory does say:
>
> AtaAtapiPassThru driver to provide native IDE/AHCI mode support
>
> So, you could
> - add "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf" to
> both OvmfPkgX64.dsc and .fdf (for the syntax, check out how the virtio
> drivers, for example "OvmfPkg/VirtioBlkDxe/VirtioBlk.inf", are included),
> - rebuild OVMF, and
> - boot it on a qemu where you enable AHCI on the command line.
>
> >
> >>
> >>> 54. usb-ohci 55. esp-scsi 56. lsi-scsi
> >>> 57. magasas
> >>
> >> These look like various SCSI HBA's. edk2 probably has no drivers,
> >> indeed. I'm not convinced we need to support them.
> >
> >>
> >>> 58. usb-uas 59. usb-xhci
> >>
> >> I think the same applies to XHCI as to AHCI, see
> >> MdeModulePkg/Bus/Pci/XhciDxe.
> >>
> >>> 60. cpu-hotplug
> >>> 61. acpi-dbug 62. VGA-std 63. PIIX4 PM 64. pci-hotplug
> >>
> >> I'm not sure if CPU and/or PCI hotplug is very useful during the
> >> firmware's lifetime (and I don't know if the above SeaBIOS files imply
> >> such support). If you mean the ACPI dependencies, they should come "for
> >> free" once we have the ACPI download patch in place.
> > if OVMF could download ACPI table from qemu. I think CPU/PCI hotplug
> > will be supported.
>
> I did test PCI hot-plug / hot-unplug once, in a Windows guest, with the
> ACPI download patch in place. I used a virtio-blk device as victim:
>
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3917/focus=4891
>
> >
> >>
> >>> 65. GPE 66. hpet 67. q35 68. pvpanic
> >>> 69. processor table 70. smm
> >>
> >> No SMM in OVMF; KVM doesn't support it (last I heard). edk2 has
> >> extensive support for SMM otherwise.
how did edk2 to support SMM?
> >
> >>
> >>> 71. pnp bios
> >>
> >> Not sure what to make of this. I'll have a few words about CSM.
> >
> > Does not pnp bios required in OVMF/EFI? or another way to do the same?
>
> 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.
>
> >
> >>
> >>> 72. gdb
> >>
> >> Source level debugging of OVMF is not solved / supported, at leat not by
> >> tools in the upstream tree. There have been elaborate and working hacks
> >> but they've gone stale. For me personally debug messages beat anything
> >> and everything and lack of gdb is a non-issue.
> >>
> >>>
> >>> ---------------------------------------------------------------------
> >>> C: OVMF does not need to support feature which seabios support
> >>> (due to UEFI's spec/implementation)
> >>> ---------------------------------------------------------------------
> >>> 73. ramdisk 74. lzma decoder
> >>
> >> Actually edk2 uses LZMA quite a bit. Most of the firmware image is
> >> compressed.
> > oh I see.
> >>
> >>> 75. biostable 76. coreboot
> >>
> >> There are efforts to support coreboot and OVMF in combination (google
> >> CorebootPkg). I have no clue of the scope, and it's not upstream.
> >>
> >>> 77. shadow 78. apm
> >>>
> >>> D: OVMF supports feature which is required by UEFI spec
> >>> 79. CSM
> >>
> >> David Woodhouse and Kevin O'Connor have done huge work to make this
> >> work, covering both SeaBIOS and edk2/OVMF.
> >>
> >> The edk2 patches are not in-tree yet. Actually the precise set of the
> >> edk2 patches to include is not fully "agreed upon" yet. In my local tree
> >> I carry the two critical patches from David on a topic branch. Gerd's
> >> RPMs also provide a pure-UEFI *and* a CSM build of OVMF. (The flavor you
> >> want must be specified at build time.)
> > oh, this mean the patches of OVMF is not fully applied. in other words,
> > we can't use OVMF with CSM to start legacy OS yet. right?
>
> 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.
> >>
> >>> 80. GPT 81. secureboot
> >>
> >> Yes. (Side note: secure boot is per-spec incompatible with CSM.)
> >>
> >>>
> >>> ---------------------------------------------------------------------
> >>> E: OVMF does not support feature which is required by UEFI spec
> >>> ---------------------------------------------------------------------
> >>> 82. i18n
> >>
> >> This is incorrect I'd think (it depends on the scope you have in mind of
> >> course): edk2 has super-extensive support for HII, which covers fonts,
> >> languages etc.
> > I just mean that currently there were only two languages: English and
> > French, and i18n should have more language support.
>
> 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
------------------------------------------------------------------------------
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
