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