From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B7C3E2034D83A for ; Tue, 7 Nov 2017 06:02:25 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70B403DE31; Tue, 7 Nov 2017 14:06:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 70B403DE31 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-130.rdu2.redhat.com [10.10.123.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 697FF60BE3; Tue, 7 Nov 2017 14:06:23 +0000 (UTC) To: Hangaohuai Cc: "edk2-devel@lists.01.org" , Igor Mammedov References: <643686C90A8F6046B2C3783E2A7A06AD3DDBC439@dggeml506-mbs.china.huawei.com> <9e30407e-8518-2fef-21bf-021240685a1a@redhat.com> <643686C90A8F6046B2C3783E2A7A06AD3DDC1320@dggeml506-mbs.china.huawei.com> From: Laszlo Ersek Message-ID: Date: Tue, 7 Nov 2017 15:06:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <643686C90A8F6046B2C3783E2A7A06AD3DDC1320@dggeml506-mbs.china.huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 07 Nov 2017 14:06:24 +0000 (UTC) Subject: Re: [Help] UEFI boot KVM4T vm hang On TianoCore X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 14:02:25 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/07/17 03:39, Hangaohuai wrote: > Hi, Laszlo Ersek; > Thanks for your reply. > > I have trying to shoot this trouble: > > 1. edk get the MtrrValidBitsMask by "AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, &VirPhyAddressSize.Uint32, NULL, NULL, NULL); "(0x80000008) > 2. Cpuid(0x80000008) is held in kvm struct (&vcpu->arch.cpuid_entries[i]) > 3. (0x80000008) is set by qemu; > > Part1: > We set the 4294967296, the "GetFirstNonAddress: Pci64Base=0x44800000000" > But the MtrrValidBitsMask get 0x3FF FFFF FFFF; > Does not pass the check. > MtrrLibInitializeMtrrMask (&MtrrValidBitsMask, &MtrrValidAddressMask); > if (((BaseAddress & ~MtrrValidAddressMask) != 0) || (Length & ~MtrrValidAddressMask) != 0) { > return RETURN_UNSUPPORTED; > } > > Part2: > Xhci_hcd will use the address above maxMemory, so we visit the wrong address. > Checking by starting a 3294967296 memory with USB3.0. > > So , I think edk2 is ok; maxMemory depend on CPU support more the 42bit. That's right; if you look at /proc/cpuinfo on your KVM host, it will say something like: address sizes : 39 bits physical, 48 bits virtual ^^^^^^^^^^^^^^^^ (the actual number will vary). With EPT enabled (see "/sys/module/kvm_intel/parameters/ept"), the guest cannot have a larger guest-phys address space than what's supported by the host CPU's physical address width. Thanks, Laszlo > > > *********************** > Hi, > > sorry about the delayed response. > > CC'ing Igor, and commenting below: > > On 10/31/17 15:29, Hangaohuai wrote: >> Hi, Laszlo Ersek; >> >> I have tested the uefi booting KVM vm with the configuration(xml); but >> start hang. >> Enable the memoryhotplug, with usb3.0 config. The config as Config1 >> below. >> >> Tested branches: >> UDK2017 eea98eea4ccbb1d640657770bccb5497fddc6064 >> Master 76fd5a660d704538a1b14a58d03a4eef9682b01c >> >> Both hang on the snapshot TianoCore in VNC >> >> Try to shoot the problem; >> I find the early version can boot success with the same config. >> Maybe the patch1 below cause the problem; >> >> Try to ignore the patch does, the master/ UDK2017 both can boot >> success. >> But I don't know why. Hope for your help,thanks. >> >> Patch1 >> *********************************************** >> commit 4f5eff8193096eb847639f090a7dfae3cff95fde >> Author: Laszlo Ersek >> Date: Fri Mar 4 20:06:26 2016 +0100 >> >> OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture >> >> diff --git a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c >> b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib >> index 3e02778..1d3d10a 100644 >> --- a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c >> +++ b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c >> @@ -132,6 +132,13 @@ InitRootBridge ( >> RootBus->MemAbove4G.Base = 0; >> RootBus->MemAbove4G.Limit = 0; >> + if (PcdGet64 (PcdPciMmio64Size) > 0) { >> + RootBus->AllocationAttributes |= EFI_PCI_HOST_BRIDGE_MEM64_DECODE; >> + RootBus->MemAbove4G.Base = PcdGet64 (PcdPciMmio64Base); >> + RootBus->MemAbove4G.Limit = PcdGet64 (PcdPciMmio64Base) + >> + (PcdGet64 (PcdPciMmio64Size) - >> + 1); } >> + >> RootBus->Bus.Base = RootBusNumber; >> RootBus->Bus.Limit = MaxSubBusNumber; >> RootBus->Io.Base = PcdGet64 (PcdPciIoBase); >> diff --git a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf >> b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeL >> index bbec746..7a964c7 100644 >> --- a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf >> +++ b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf >> @@ -51,4 +51,6 @@ >> gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize >> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base >> gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size >> + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base >> + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId >> *********************************************** >> >> >> Config1 >> *********************************************** >> 4294967296 >> 4294967 >> 4294967 >> Xxxx >> >>
> function='0x0'/> >> *********************************************** > > The patch that you identified is responsible for exposing the 64-bit MMIO aperture for PCI MMIO BAR allocation purposes. > > Reverting this patch might mask the issue, but I don't expect the actual problem to be in this patch. > > Instead, the base address and the size of the aperture in question is determined in the file > > OvmfPkg/PlatformPei/MemDetect.c > > in the function > > GetFirstNonAddress() > > This function takes the memory (DIMM) hotplug range in question, the end of which is presented by QEMU in the fw_cfg file > > etc/reserved-memory-end > > To my knowledge, this fw_cfg file is an 8-byte integer in LE encoding. > > Quoting the code: > >> // >> // If QEMU presents an E820 map, then get the highest exclusive >=4GB RAM >> // address from it. This can express an address >= 4GB+1TB. >> // >> // Otherwise, get the flat size of the memory above 4GB from the CMOS (which >> // can only express a size smaller than 1TB), and add it to 4GB. >> // >> Status = ScanOrAdd64BitE820Ram (&FirstNonAddress); >> if (EFI_ERROR (Status)) { >> FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb (); >> } >> >> ... >> >> // >> // The "etc/reserved-memory-end" fw_cfg file, when present, contains an >> // absolute, exclusive end address for the memory hotplug area. This area >> // starts right at the end of the memory above 4GB. The 64-bit PCI host >> // aperture must be placed above it. >> // >> Status = QemuFwCfgFindFile ("etc/reserved-memory-end", &FwCfgItem, >> &FwCfgSize); >> if (!EFI_ERROR (Status) && FwCfgSize == sizeof HotPlugMemoryEnd) { >> QemuFwCfgSelectItem (FwCfgItem); >> QemuFwCfgReadBytes (FwCfgSize, &HotPlugMemoryEnd); >> >> ASSERT (HotPlugMemoryEnd >= FirstNonAddress); >> FirstNonAddress = HotPlugMemoryEnd; >> } > > Can you check if the ASSERT fires for you? > > For that, please capture the OVMF debug log like this: > > (1) build OVMF with the following flag: > > --pcd=gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel=0x8040004F > > (2) modify your domain XML as follows: > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <--- don't forget this attribute! > > > > > > > > > Then the file "/tmp/ovmf.log" should contain a verbose OVMF log -- please attach it. > > Thanks > Laszlo >