From mboxrd@z Thu Jan 1 00:00:00 1970 From: Janusz Mocek Subject: Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled Date: Tue, 20 Oct 2015 20:52:44 +0200 Message-ID: <56268D7C.1020308@gmail.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> <56267D99.2080900@redhat.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: Laszlo Ersek , "Kinney, Michael D" , Xiao Guangrong Return-path: Received: from mail-lb0-f174.google.com ([209.85.217.174]:35367 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbbJTSwu (ORCPT ); Tue, 20 Oct 2015 14:52:50 -0400 Received: by lbbes7 with SMTP id es7so22295915lbb.2 for ; Tue, 20 Oct 2015 11:52:48 -0700 (PDT) In-Reply-To: <56267D99.2080900@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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