W dniu 20.10.2015 o 19:44, Laszlo Ersek pisze: > Hi, > > On 10/20/15 19:27, Janusz wrote: >> W dniu 15.10.2015 o 20:46, Laszlo Ersek pisze: >>> On 10/15/15 18:53, Kinney, Michael D wrote: >>>> Laszlo, >>>> >>>> There is already a PCD for this timeout that is used by CpuMpPei. >>>> >>>> gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds >>>> >>>> I noticed that CpuDxe is using a hard coded AP timeout. I think we should just use this same PCD for both the PEI and DXE CPU module and then set it for OVMF to the compatible value. >>> Perfect, thank you! >>> >>> (I notice the default in the DEC file is 50000, which is half of what >>> the DXE driver hardcodes.) >>> >>> Now we only need a recommended (or experimental) value for it, and an >>> explanation why 100*1000 is no longer sufficient on KVM :) >>> >>> Thanks! >>> Laszlo >>> >>> >>> >> Laszlo, >> >> I saw that there is already some change in ovmf for MicroSecondDelay >> https://github.com/tianocore/edk2/commit/1e410eadd80c328e66868263b3006a274ce81ae0 >> Is that a fix for it? Because I tried it and it still doesn't work for >> me: https://bpaste.net/show/2514b51bf41f >> I still get internal error > I think you guys are now "mature enough OVMF users" to start employing > the correct terminology. Sory for that :) > "edk2" (also spelled as "EDK II") is: "a modern, feature-rich, > cross-platform firmware development environment for the UEFI and PI > specifications". > > The source tree contains a whole bunch of modules (drivers, > applications, libraries), organized into packages. > > "OVMF" usually denotes a firmware binary built from one of the > OvmfPkg/OvmfPkg*.dsc "platform description files". Think of them as "top > level makefiles". The difference between them is the target architecture > (there's Ia32, X64, and Ia32X64 -- the last one means that the SEC and > PEI phases are 32-bit, whereas the DXE and later phases are 64-bit.) In > practice you'll only care about full X64. > > Now, each of OvmfPkg/OvmfPkg*.dsc builds the following three kinds of > modules into the final binary: > - platform-independent modules from various top-level packages > - platform- (ie. Ia32/X64-) dependent modules from various top-level > packages > - modules from under OvmfPkg that are specific to QEMU/KVM (and Xen, if > you happen to use OVMF with Xen) > > Now, when you reference a commit like 1e410ead above, you can look at > the diffstat, and decide if it is OvmfPkg-specific (third category > above) or not. Here you see UefiCpuPkg, which happens to be the second > category. > > The important point is: please do *not* call any and all edk2 patches > "OVMF changes", indiscriminately. That's super confusing for people who > understand the above distinctions. Which now you do too. :) > > Let me add that in edk2, patches that straddle top level packages are > generally forbidden -- you can't have a patch that modifies OvmfPkg and > UefiCpuPkg at the same time, modulo *very* rare exceptions. If a feature > or bugfix needs to touch several top-level packages, the series must be > built up carefully in stages. > > Knowing all of the above, you can tell that the patch you referenced had > only *enabled* OvmfPkg to customize UefiCpuPkg, via > "PcdCpuApInitTimeOutInMicroSeconds". But for that customization to occur > actually, a small patch for OvmfPkg will be necessary too, in order to > set "PcdCpuApInitTimeOutInMicroSeconds" differently from the default. > > I plan to send that patch soon. If you'd like to be CC'd, that's great > (reporting back with a Tested-by is even better!), but I'll need your > real name for that. (Or any name that looks like a real name.) would be great if you could add me to cc list, thanks > > Thanks! > Laszlo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
