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. 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.
You're right, the suspend is also unstable. when I suspend a F18 guest,
it caused reboot occasionally.
>
> >
> >>>
> >>>>
> >>>>> 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.
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.
> >>
> >>>
> >>>>
> >>>>> 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.
Ok, thanks.
Best regards,
Chen
>
> 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
