From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled Date: Tue, 20 Oct 2015 19:44:57 +0200 Message-ID: <56267D99.2080900@redhat.com> References: <55FBDB6D.4040207@gmail.com> <55FBE248.4010809@redhat.com> <55FC4E6F.8030104@gmail.com> <55FF7095.5060106@linux.intel.com> <55FF7C41.7070400@linux.intel.com> <560D3F31.5000703@gmail.com> <560D40C2.5080205@redhat.com> <560E96D8.9080007@gmail.com> <561DD2EC.5040800@linux.intel.com> <561E0655.8080508@gmail.com> <561E1121.7030502@linux.intel.com> <561E1329.5080109@linux.intel.com> <561E9A36.3080302@gmail.com> <561F2952.5060300@linux.intel.com> <561F4589.5050609@gmail.com> <561F4AAE.3060204@linux.intel.com> <561F4E92.3090403@gmail.com> <561F516D.7070504@linux.intel.com> <561FD1D8.3030605@redhat.com> <561FF492.90608@redhat.com> <5626797C.2020108@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" , "Justen, Jordan L" , "edk2-devel@ml01.01.org" , Alex Williamson , Chen Fan , Paolo Bonzini , Wanpeng Li To: Janusz , "Kinney, Michael D" , Xiao Guangrong Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43536 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752537AbbJTRpB (ORCPT ); Tue, 20 Oct 2015 13:45:01 -0400 In-Reply-To: <5626797C.2020108@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 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