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. "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.) 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
