mirror of
https://github.com/xemu-project/xemu.git
synced 2024-11-27 13:30:52 +00:00
0cf8882fd0
There may be some differences in pci resource assignment between guest os and firmware. Eg. A Bridge with Bus [d2] -+-[0000:d2]---01.0-[d3]----01.0 where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256] [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K] BAR4 (mem, 64-bit, pref) [size=64M] In EDK2, the Resource Map would be: PciBus: Resource Map for Bridge [D2|01|00] Type = PMem64; Base = 0x8004000000; Length = 0x4100000; Alignment = 0x3FFFFFF Base = 0x8004000000; Length = 0x4000000; Alignment = 0x3FFFFFF; Owner = PCI [D3|01|00:20] Base = 0x8008000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [D3|01|00:10] Type = Mem64; Base = 0x8008100000; Length = 0x100; Alignment = 0xFFF It would use 0x4100000 to calculate the root bus's PMem64 resource window. While in Linux, kernel will use 0x1FFFFFF as the alignment to calculate the PMem64 size, which would be 0x6000000. So kernel would try to allocate 0x6000000 from the PMem64 resource window, but since the window size is 0x4100000 as assigned by EDK2, the allocation would fail. The diffences could result in resource assignment failure. Using _DSM #5 method to inform guest os not to ignore the PCI configuration that firmware has done at boot time could handle the differences. Acked-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Message-Id: <20210114100643.10617-5-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> |
||
---|---|---|
.. | ||
bonito.c | ||
designware.c | ||
gpex-acpi.c | ||
gpex.c | ||
grackle.c | ||
i440fx.c | ||
Kconfig | ||
meson.build | ||
pam.c | ||
pnv_phb3_msi.c | ||
pnv_phb3_pbcq.c | ||
pnv_phb3.c | ||
pnv_phb4_pec.c | ||
pnv_phb4.c | ||
ppce500.c | ||
prep.c | ||
q35.c | ||
sabre.c | ||
trace-events | ||
trace.h | ||
uninorth.c | ||
versatile.c | ||
xen_igd_pt.c | ||
xilinx-pcie.c |