* [Help] UEFI boot KVM4T vm hang On TianoCore
@ 2017-10-31 14:29 Hangaohuai
2017-11-06 19:10 ` Laszlo Ersek
0 siblings, 1 reply; 4+ messages in thread
From: Hangaohuai @ 2017-10-31 14:29 UTC (permalink / raw)
To: lersek@redhat.com; +Cc: edk2-devel@lists.01.org, Hangaohuai
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 <lersek@redhat.com>
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
***********************************************
<maxMemory slots='256' unit='KiB'>4294967296</maxMemory>
<memory unit='KiB'>4294967</memory>
<currentMemory unit='KiB'>4294967</currentMemory>
Xxxx
<controller type='usb' index='2' model='nec-xhci'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1c' function='0x0'/>
</controller>
***********************************************
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Help] UEFI boot KVM4T vm hang On TianoCore
2017-10-31 14:29 [Help] UEFI boot KVM4T vm hang On TianoCore Hangaohuai
@ 2017-11-06 19:10 ` Laszlo Ersek
2017-11-07 2:39 ` Hangaohuai
0 siblings, 1 reply; 4+ messages in thread
From: Laszlo Ersek @ 2017-11-06 19:10 UTC (permalink / raw)
To: Hangaohuai; +Cc: edk2-devel@lists.01.org, Igor Mammedov
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 <lersek@redhat.com>
> 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
> ***********************************************
> <maxMemory slots='256' unit='KiB'>4294967296</maxMemory>
> <memory unit='KiB'>4294967</memory>
> <currentMemory unit='KiB'>4294967</currentMemory>
> Xxxx
> <controller type='usb' index='2' model='nec-xhci'>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x1c' function='0x0'/>
> </controller>
> ***********************************************
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:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <--- don't forget this attribute!
<qemu:commandline>
<qemu:arg value='-global'/>
<qemu:arg value='isa-debugcon.iobase=0x402'/>
<qemu:arg value='-debugcon'/>
<qemu:arg value='file:/tmp/ovmf.log'/>
</qemu:commandline>
</domain>
Then the file "/tmp/ovmf.log" should contain a verbose OVMF log --
please attach it.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Help] UEFI boot KVM4T vm hang On TianoCore
2017-11-06 19:10 ` Laszlo Ersek
@ 2017-11-07 2:39 ` Hangaohuai
2017-11-07 14:06 ` Laszlo Ersek
0 siblings, 1 reply; 4+ messages in thread
From: Hangaohuai @ 2017-11-07 2:39 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel@lists.01.org, Igor Mammedov
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 <maxMemory slots='256' unit='KiB'>4294967296</maxMemory>, 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 <maxMemory slots='256' unit='KiB'>3294967296</maxMemory> 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
> 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 <lersek@redhat.com>
> 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
> ***********************************************
> <maxMemory slots='256' unit='KiB'>4294967296</maxMemory>
> <memory unit='KiB'>4294967</memory>
> <currentMemory unit='KiB'>4294967</currentMemory>
> Xxxx
> <controller type='usb' index='2' model='nec-xhci'>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x1c'
> function='0x0'/> </controller>
> ***********************************************
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:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <--- don't forget this attribute!
<qemu:commandline>
<qemu:arg value='-global'/>
<qemu:arg value='isa-debugcon.iobase=0x402'/>
<qemu:arg value='-debugcon'/>
<qemu:arg value='file:/tmp/ovmf.log'/>
</qemu:commandline>
</domain>
Then the file "/tmp/ovmf.log" should contain a verbose OVMF log -- please attach it.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Help] UEFI boot KVM4T vm hang On TianoCore
2017-11-07 2:39 ` Hangaohuai
@ 2017-11-07 14:06 ` Laszlo Ersek
0 siblings, 0 replies; 4+ messages in thread
From: Laszlo Ersek @ 2017-11-07 14:06 UTC (permalink / raw)
To: Hangaohuai; +Cc: edk2-devel@lists.01.org, Igor Mammedov
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 <maxMemory slots='256' unit='KiB'>4294967296</maxMemory>, 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 <maxMemory slots='256' unit='KiB'>3294967296</maxMemory> 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 <lersek@redhat.com>
>> 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
>> ***********************************************
>> <maxMemory slots='256' unit='KiB'>4294967296</maxMemory>
>> <memory unit='KiB'>4294967</memory>
>> <currentMemory unit='KiB'>4294967</currentMemory>
>> Xxxx
>> <controller type='usb' index='2' model='nec-xhci'>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x1c'
>> function='0x0'/> </controller>
>> ***********************************************
>
> 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:
>
> <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <--- don't forget this attribute!
> <qemu:commandline>
> <qemu:arg value='-global'/>
> <qemu:arg value='isa-debugcon.iobase=0x402'/>
> <qemu:arg value='-debugcon'/>
> <qemu:arg value='file:/tmp/ovmf.log'/>
> </qemu:commandline>
> </domain>
>
> Then the file "/tmp/ovmf.log" should contain a verbose OVMF log -- please attach it.
>
> Thanks
> Laszlo
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-07 14:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-31 14:29 [Help] UEFI boot KVM4T vm hang On TianoCore Hangaohuai
2017-11-06 19:10 ` Laszlo Ersek
2017-11-07 2:39 ` Hangaohuai
2017-11-07 14:06 ` Laszlo Ersek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox