From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=45.249.212.189; helo=szxga03-in.huawei.com; envelope-from=hangaohuai@huawei.com; receiver=edk2-devel@lists.01.org Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 012612035D114 for ; Mon, 6 Nov 2017 18:36:17 -0800 (PST) Received: from 172.30.72.56 (EHLO DGGEML403-HUB.china.huawei.com) ([172.30.72.56]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AYH78763; Tue, 07 Nov 2017 10:40:05 +0800 (CST) Received: from DGGEML506-MBS.china.huawei.com ([169.254.10.249]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 10:39:57 +0800 From: Hangaohuai To: Laszlo Ersek CC: "edk2-devel@lists.01.org" , Igor Mammedov Thread-Topic: [Help] UEFI boot KVM4T vm hang On TianoCore Thread-Index: AQHTVzMAvqpfBhRevEKpZyZjfC0T2qMIKYFQ Date: Tue, 7 Nov 2017 02:39:57 +0000 Message-ID: <643686C90A8F6046B2C3783E2A7A06AD3DDC1320@dggeml506-mbs.china.huawei.com> References: <643686C90A8F6046B2C3783E2A7A06AD3DDBC439@dggeml506-mbs.china.huawei.com> <9e30407e-8518-2fef-21bf-021240685a1a@redhat.com> In-Reply-To: <9e30407e-8518-2fef-21bf-021240685a1a@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.23.7] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5A011D07.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.249, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a90fa81d9b4d6a8dfacf5184749833c5 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 02:36:20 -0000 Content-Language: zh-CN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, th= e "GetFirstNonAddress: Pci64Base=3D0x44800000000" But the MtrrValidBitsMask get 0x3FF FFFF FFFF; Does not pass the check. MtrrLibInitializeMtrrMask (&MtrrValidBitsMask, &MtrrValidAddressMask); if (((BaseAddress & ~MtrrValidAddressMask) !=3D 0) || (Length & ~MtrrVali= dAddressMask) !=3D 0) { return RETURN_UNSUPPORTED; } Part2: Xhci_hcd will use the address above maxMemory, so we visit the wrong addres= s. Checking by starting a 3294967296 memory with USB3.0. So , I think edk2 is ok; maxMemory depend on CPU support more the 42bit. *********************** 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=20 > start hang. > Enable the memoryhotplug, with usb3.0 config. The config as Config1=20 > 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=20 > 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=20 > 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 =3D 0; > RootBus->MemAbove4G.Limit =3D 0; > + if (PcdGet64 (PcdPciMmio64Size) > 0) { > + RootBus->AllocationAttributes |=3D EFI_PCI_HOST_BRIDGE_MEM64_DECODE; > + RootBus->MemAbove4G.Base =3D PcdGet64 (PcdPciMmio64Base); > + RootBus->MemAbove4G.Limit =3D PcdGet64 (PcdPciMmio64Base) + > + (PcdGet64 (PcdPciMmio64Size) -=20 > + 1); } > + > RootBus->Bus.Base =3D RootBusNumber; > RootBus->Bus.Limit =3D MaxSubBusNumber; > RootBus->Io.Base =3D PcdGet64 (PcdPciIoBase); > diff --git a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf=20 > 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=3D'0x0'/> > *********************************************** The patch that you identified is responsible for exposing the 64-bit MMIO a= perture for PCI MMIO BAR allocation purposes. Reverting this patch might mask the issue, but I don't expect the actual pr= oblem to be in this patch. Instead, the base address and the size of the aperture in question is deter= mined 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 >=3D4GB= RAM > // address from it. This can express an address >=3D 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 =3D ScanOrAdd64BitE820Ram (&FirstNonAddress); > if (EFI_ERROR (Status)) { > FirstNonAddress =3D 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 ar= ea > // starts right at the end of the memory above 4GB. The 64-bit PCI host > // aperture must be placed above it. > // > Status =3D QemuFwCfgFindFile ("etc/reserved-memory-end", &FwCfgItem, > &FwCfgSize); > if (!EFI_ERROR (Status) && FwCfgSize =3D=3D sizeof HotPlugMemoryEnd) { > QemuFwCfgSelectItem (FwCfgItem); > QemuFwCfgReadBytes (FwCfgSize, &HotPlugMemoryEnd); > > ASSERT (HotPlugMemoryEnd >=3D FirstNonAddress); > FirstNonAddress =3D 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=3DgEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel=3D0x8040004F (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 a= ttach it. Thanks Laszlo