Bug 1323976
Summary: | PCI: Add 64-bit MMIO support to PXB devices | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Marcel Apfelbaum <marcel> | ||||||||||
Component: | qemu-kvm-rhev | Assignee: | Marcel Apfelbaum <marcel> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | jingzhao <jinzhao> | ||||||||||
Severity: | low | Docs Contact: | |||||||||||
Priority: | low | ||||||||||||
Version: | 7.2 | CC: | ailan, chayang, huding, jinzhao, juzhang, lersek, marcel, mrezanin, virt-maint, xfu | ||||||||||
Target Milestone: | rc | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | qemu-kvm-rhev-2.6.0-19.el7 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2016-11-07 21:04:06 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Marcel Apfelbaum
2016-04-05 08:51:05 UTC
Laszlo posted a first version upstream: [Qemu-devel] [PATCH] hw/i386/acpi-build: place qword descriptors in bridge _CRS's when needed (https://www.mail-archive.com/qemu-devel@nongnu.org/msg359550.html). I will send a new version based on the above patch. Patches posted upstream: https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg00090.html Marcel's v2 upstream series: http://thread.gmane.org/gmane.comp.emulators.qemu/411649 Hi Marcel Could you share more info? How can we check the difference, the seabios log, dmesg info of guest or other info ? Also, boot up guest with pxb-pcie devices(refer to bug1272939) when checking the memory range, right? Thanks Jing Zhao Jing Zhao, (In reply to jingzhao from comment #4) > Hi Marcel > > Could you share more info? How can we check the difference, the seabios > log, dmesg info of guest or other info ? > > Also, boot up guest with pxb-pcie devices(refer to bug1272939) when > checking the memory range, right? You can read about how I tested these changes for upstream in this message: https://www.mail-archive.com/qemu-devel@nongnu.org/msg382955.html Basically, the test consists of the following steps: - create an OVMF virtual machine - use virtio 1.0 (modern) virtio devices - put at least one virtio 1.0 device behind a pxb-pcie device - in the guest, check "/proc/iomem", and confirm that the MMIO for the device(s) behind the pxb-pcie extra root bridges are located above 4GB - in the guest, use "acpidump" and "iasl -d" on the DSDT, and confirm the same in the _CRS objects - the guest dmesg should not complain about resource allocation / claiming - actually test the virtio device (see if it works) - check the OVMF log for the PciBus: Resource Map for Root Bridge ... sections, and see where the individual MMIO BARs are located -- they should be consistent with the "/proc/iomem" check. (Marcel, if you agree this is a sufficient test, feel free to clear the NEEDINFO request.) (In reply to Laszlo Ersek from comment #5) > Jing Zhao, > > (In reply to jingzhao from comment #4) > > Hi Marcel > > > > Could you share more info? How can we check the difference, the seabios > > log, dmesg info of guest or other info ? > > > > Also, boot up guest with pxb-pcie devices(refer to bug1272939) when > > checking the memory range, right? > > You can read about how I tested these changes for upstream in this message: > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg382955.html > > Basically, the test consists of the following steps: > - create an OVMF virtual machine > - use virtio 1.0 (modern) virtio devices > - put at least one virtio 1.0 device behind a pxb-pcie device > - in the guest, check "/proc/iomem", and confirm that the MMIO for the > device(s) > behind the pxb-pcie extra root bridges are located above 4GB > - in the guest, use "acpidump" and "iasl -d" on the DSDT, and confirm the > same > in the _CRS objects > - the guest dmesg should not complain about resource allocation / claiming > - actually test the virtio device (see if it works) > - check the OVMF log for the > PciBus: Resource Map for Root Bridge ... > sections, and see where the individual MMIO BARs are located -- they should > be consistent with the "/proc/iomem" check. > > (Marcel, if you agree this is a sufficient test, feel free to clear the > NEEDINFO request.) Hi Laszlo, Thank you for the help. Indeed your proposed test is clear and sufficient. Thanks, Marcel Fix included in qemu-kvm-rhev-2.6.0-19.el7 Hi Marcel and laszlo Test it on host kernel:3.10.0-492.el7.x86_64 and qemu-kvm-rhev-2.6.0-20.el7.x86_64. Following is the test steps 1. Boot ovmf vm with following command /usr/libexec/qemu-kvm \ -M q35 \ -monitor stdio \ -vnc :20 \ -m 4G \ -vga std \ -smp 2,sockets=2,cores=1,threads=1 \ -object memory-backend-ram,size=2048M,id=ram-node0 \ -numa node,nodeid=0,cpus=0,memdev=ram-node0 \ -object memory-backend-ram,size=2048M,id=ram-node1 \ -numa node,nodeid=1,cpus=1,memdev=ram-node1 \ -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \ -serial unix:/tmp/serial0,server,nowait \ -debugcon file:/home/bug/ovmf.log \ -global isa-debugcon.iobase=0x402 \ -device pxb-pcie,id=bridge2,bus=pcie.0,numa_node=0,bus_nr=8 \ -device ioh3420,bus=bridge2,id=root.0,slot=1 \ -drive if=none,id=drive1,file=/home/bug/block.qcow2,format=qcow2 \ -device virtio-blk-pci,drive=drive1,scsi=off,bus=root.0 \ -device pxb-pcie,id=bridge3,bus=pcie.0,numa_node=1,bus_nr=40 \ -device ioh3420,bus=bridge3,id=root.1,slot=2 \ -drive if=none,id=drive0,file=/home/bug/ovmf.qcow2,format=qcow2 \ -device virtio-blk-pci,drive=drive0,scsi=off,bus=root.1,bootindex=1 \ -device ioh3420,id=root.2,slot=3 \ -device x3130-upstream,bus=root.2,id=upstream1 \ -device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \ -device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \ -device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \ -device virtio-net-pci,bus=downstream1,netdev=tap10,mac=9a:6a:6b:6c:6d:6e -netdev tap,id=tap10 \ 2. In guest, check the virtio devices belong to virtio-1.0 devices [root@localhost home]# lspci 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:02.0 Host bridge: Red Hat, Inc. Device 000b 00:03.0 Host bridge: Red Hat, Inc. Device 000b 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 08:00.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 09:00.0 SCSI storage controller: Red Hat, Inc Virtio block device (rev 01) 28:00.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 28:01.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 29:00.0 SCSI storage controller: Red Hat, Inc Virtio block device (rev 01) 2a:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Upstream) (rev 02) 2b:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2b:01.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2b:02.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2c:00.0 Ethernet controller: Red Hat, Inc Virtio network device (rev 01) [root@localhost home]# lspci -vvv -t -+-[0000:28]-+-00.0-[29]----00.0 Red Hat, Inc Virtio block device | \-01.0-[2a-2e]----00.0-[2b-2e]--+-00.0-[2c]----00.0 Red Hat, Inc Virtio network device | +-01.0-[2d]-- | \-02.0-[2e]-- +-[0000:08]---00.0-[09]----00.0 Red Hat, Inc Virtio block device \-[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Device 000b +-03.0 Red Hat, Inc. Device 000b +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller [root@localhost home]# cat /sys/bus/pci/devices/0000\:09\:00.0/virtio2/features 0010101001110000000000000000110010000000000000000000000000000000 [root@localhost home]# cat /sys/bus/pci/devices/0000\:29\:00.0/virtio0/features 0010101001110000000000000000110010000000000000000000000000000000 [root@localhost home]# cat /sys/bus/pci/devices/0000\:2c\:00.0/virtio1/features 1100011111111111111101010000110010000000000000000000000000000000 3. Make sure the virtio devices works [root@localhost home]# ping 10.66.4.211 PING 10.66.4.211 (10.66.4.211) 56(84) bytes of data. 64 bytes from 10.66.4.211: icmp_seq=1 ttl=64 time=1.81 ms 64 bytes from 10.66.4.211: icmp_seq=2 ttl=64 time=0.932 ms ^C --- 10.66.4.211 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.932/1.375/1.818/0.443 ms [root@localhost home]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 30G 0 disk ├─vda1 252:1 0 200M 0 part /boot/efi ├─vda2 252:2 0 1G 0 part /boot └─vda3 252:3 0 28.8G 0 part ├─rhel-root 253:0 0 26.8G 0 lvm / └─rhel-swap 253:1 0 2G 0 lvm [SWAP] vdb 252:16 0 1G 0 disk [root@localhost home]# dd if=/dev/zero of=/dev/vdb bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 0.357225 s, 1.5 GB/s 4.Check the dmesg in the guest, please check the attachment (found "[ 0.720725] pci 0000:2b:01.0: BAR 15: no space for [mem size 0x00200000 64bit pref] [ 0.720727] pci 0000:2b:01.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref] " and I think https://bugzilla.redhat.com/show_bug.cgi?id=1348798 can track the error), so I think it's ok in dmesg 5.In guest, check the iomem [root@localhost home]# cat /proc/iomem 00000000-00000fff : reserved 00001000-0009dfff : System RAM 0009e000-0009efff : reserved 0009f000-0009ffff : ACPI Non-volatile Storage 000a0000-000bffff : PCI Bus 0000:00 000f0000-000fffff : System ROM 00100000-7dbcc017 : System RAM 02000000-0269afca : Kernel code 0269afcb-02af4aff : Kernel data 02ca1000-02fa2fff : Kernel bss 2d000000-370fffff : Crash kernel 7dbcc018-7dbee857 : System RAM 7dbee858-7e16afff : System RAM 7e16b000-7e16bfff : ACPI Tables 7e16c000-7e16cfff : ACPI Non-volatile Storage 7e16d000-7e183017 : System RAM 7e183018-7e18c657 : System RAM 7e18c658-7e533fff : System RAM 7e534000-7e54ffff : reserved 7e550000-7e56ffff : System RAM 7e570000-7e590fff : reserved 7e591000-7e5cdfff : System RAM 7e5ce000-7e5ddfff : reserved 7e5de000-7e5edfff : ACPI Non-volatile Storage 7e5ee000-7f6a2fff : System RAM 7f6a3000-7f6fafff : reserved 7f6fb000-7f702fff : ACPI Tables 7f703000-7f706fff : ACPI Non-volatile Storage 7f707000-7f7cffff : System RAM 7f7d0000-7f7effff : reserved 7f7f0000-7f7fffff : System RAM 7f800000-8fffffff : reserved 80000000-8fffffff : PCI MMCONFIG 0000 [bus 00-ff] 90000000-911fffff : PCI Bus 0000:00 90000000-90ffffff : 0000:00:01.0 90000000-90ffffff : bochs-drm 91000000-91000fff : 0000:00:1f.2 91000000-91000fff : ahci 91001000-91001fff : 0000:00:01.0 91001000-91001fff : bochs-drm 91010000-9101ffff : 0000:00:01.0 91200000-913fffff : PCI Bus 0000:08 91200000-913fffff : PCI Bus 0000:09 91200000-91200fff : 0000:09:00.0 91200000-91200fff : virtio-pci 91400000-91bfffff : PCI Bus 0000:28 91400000-919fffff : PCI Bus 0000:2a 91400000-919fffff : PCI Bus 0000:2b 91400000-915fffff : PCI Bus 0000:2e 91600000-917fffff : PCI Bus 0000:2d 91800000-919fffff : PCI Bus 0000:2c 91800000-91800fff : 0000:2c:00.0 91800000-91800fff : virtio-pci 91840000-9187ffff : 0000:2c:00.0 91a00000-91bfffff : PCI Bus 0000:29 91a00000-91a00fff : 0000:29:00.0 91a00000-91a00fff : virtio-pci 91c00000-febfffff : PCI Bus 0000:00 fec00000-fec003ff : IOAPIC 0 fed1f410-fed1f414 : iTCO_wdt.0.auto fed1f410-fed1f414 : iTCO_wdt fee00000-fee00fff : Local APIC ffe00000-ffffffff : reserved 100000000-17fffffff : System RAM 800000000-8007fffff : PCI Bus 0000:08 800000000-8007fffff : PCI Bus 0000:09 800000000-8007fffff : 0000:09:00.0 800000000-8007fffff : virtio-pci 800800000-8017fffff : PCI Bus 0000:28 800800000-800ffffff : PCI Bus 0000:29 800800000-800ffffff : 0000:29:00.0 800800000-800ffffff : virtio-pci 801000000-8017fffff : PCI Bus 0000:2a 801000000-8017fffff : PCI Bus 0000:2b 801000000-8017fffff : PCI Bus 0000:2c 801000000-8017fffff : 0000:2c:00.0 801000000-8017fffff : virtio-pci And compare with the ovmf log, and " MemAbove4G: 800000000 - FFFFFFFFF" same with the "/proc/iomem" (the detailed ovmf log, please check the attachment) RootBridge: PciRoot(0x0) Support/Attr: 70069 / 70069 DmaAbove4G: No NoExtConfSpace: No AllocAttr: 3 (CombineMemPMem Mem64Decode) Bus: 0 - 7 Io: 6000 - FFFF Mem: 90000000 - FBFFFFFF MemAbove4G: 800000000 - FFFFFFFFF PMem: FFFFFFFFFFFFFFFF - 0 PMemAbove4G: FFFFFFFFFFFFFFFF - 0 PciHostBridgeDxe: IntersectMemoryDescriptor: add [800000000, 1000000000): Success RootBridge: PciRoot(0x8) Support/Attr: 70069 / 70069 DmaAbove4G: No NoExtConfSpace: No AllocAttr: 3 (CombineMemPMem Mem64Decode) Bus: 8 - 27 Io: 6000 - FFFF Mem: 90000000 - FBFFFFFF MemAbove4G: 800000000 - FFFFFFFFF PMem: FFFFFFFFFFFFFFFF - 0 PMemAbove4G: FFFFFFFFFFFFFFFF - 0 RootBridge: PciRoot(0x28) Support/Attr: 70069 / 70069 DmaAbove4G: No NoExtConfSpace: No AllocAttr: 3 (CombineMemPMem Mem64Decode) Bus: 28 - FF Io: 6000 - FFFF Mem: 90000000 - FBFFFFFF MemAbove4G: 800000000 - FFFFFFFFF PMem: FFFFFFFFFFFFFFFF - 0 PMemAbove4G: FFFFFFFFFFFFFFFF - 0 For the "- in the guest, use "acpidump" and "iasl -d" on the DSDT, and confirm the same in the _CRS objects" from coment 5 --- I didn't get the "_CRS objects" and I only test with following steps in guest and i think there are no useful info. As I understanding, QE didn't do these check in guest, am I right? [root@localhost home]# acpidump >acpidump.out [root@localhost home]# ls -lrt total 1016 drwx------. 3 guest guest 78 Aug 22 15:25 guest -rw-r--r--. 1 root root 930174 Aug 22 16:07 acpica-tools-20160729-1.fc24.x86_64.rpm -rw-r--r--. 1 root root 55860 Aug 22 16:24 tmp -rw-r--r--. 1 root root 47058 Aug 22 16:48 acpidump.out [root@localhost home]# acpixtract -a acpidump.out Intel ACPI Component Architecture ACPI Binary Table Extraction Utility version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation Acpi table [APIC] - 128 bytes written to apic.dat Acpi table [DSDT] - 9516 bytes written to dsdt.dat Acpi table [FACP] - 116 bytes written to facp.dat Acpi table [FACS] - 64 bytes written to facs.dat Acpi table [MCFG] - 60 bytes written to mcfg.dat Acpi table [SRAT] - 240 bytes written to srat.dat 6 binary ACPI tables extracted [root@localhost home]# acpidump >acpidump.out [root@localhost home]# ls -lrt total 1016 drwx------. 3 guest guest 78 Aug 22 15:25 guest -rw-r--r--. 1 root root 930174 Aug 22 16:07 acpica-tools-20160729-1.fc24.x86_64.rpm -rw-r--r--. 1 root root 55860 Aug 22 16:24 tmp -rw-r--r--. 1 root root 47058 Aug 22 16:48 acpidump.out [root@localhost home]# acpixtract -a acpidump.out Intel ACPI Component Architecture ACPI Binary Table Extraction Utility version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation Acpi table [APIC] - 128 bytes written to apic.dat Acpi table [DSDT] - 9516 bytes written to dsdt.dat Acpi table [FACP] - 116 bytes written to facp.dat Acpi table [FACS] - 64 bytes written to facs.dat Acpi table [MCFG] - 60 bytes written to mcfg.dat Acpi table [SRAT] - 240 bytes written to srat.dat 6 binary ACPI tables extracted [root@localhost home]# iasl -sa dsdt.dat Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation Binary file appears to be a valid ACPI table, disassembling Input file dsdt.dat, Length 0x252C (9516) bytes ACPI: DSDT 0x0000000000000000 00252C (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: dsdt.dsl - 99862 bytes [root@localhost home]# iasl -sa dsdt.dsl Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation dsdt.dsl 3036: Method (COST, 4, Serialized) Remark 2146 - ^ Method Argument is never used (Arg3) dsdt.dsl 3173: CreateDWordField (MR64, \_SB.PCI0.MHPD.MCRS._Y01._MIN, MINL) // _MIN: Minimum Base Address Warning 3128 - ResourceTag larger than Field ^ (Size mismatch, Tag: 64 bits, Field: 32 bits) dsdt.dsl 3175: CreateDWordField (MR64, \_SB.PCI0.MHPD.MCRS._Y01._LEN, LENL) // _LEN: Length Warning 3128 - ResourceTag larger than Field ^ (Size mismatch, Tag: 64 bits, Field: 32 bits) dsdt.dsl 3177: CreateDWordField (MR64, \_SB.PCI0.MHPD.MCRS._Y01._MAX, MAXL) // _MAX: Maximum Base Address Warning 3128 - ResourceTag larger than Field ^ (Size mismatch, Tag: 64 bits, Field: 32 bits) dsdt.dsl 3231: Method (MOST, 4, NotSerialized) Remark 2146 - ^ Method Argument is never used (Arg3) dsdt.dsl 3240: Method (MEJ0, 2, NotSerialized) Remark 2146 - ^ Method Argument is never used (Arg1) dsdt.dsl 3612: Method (MTFY, 2, NotSerialized) Remark 2146 - ^ Method Argument is never used (Arg0) dsdt.dsl 3612: Method (MTFY, 2, NotSerialized) Remark 2146 - ^ Method Argument is never used (Arg1) ASL Input: dsdt.dsl - 3660 lines, 99862 bytes, 600 keywords AML Output: dsdt.aml - 9400 bytes, 309 named objects, 291 executable opcodes ASM Source: dsdt.asm - 261944 bytes Compilation complete. 0 Errors, 3 Warnings, 5 Remarks, 40 Optimizations [root@localhost home]# acpiexec dsdt.dat Intel ACPI Component Architecture AML Execution/Debug Utility version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation Input file dsdt.dat, Length 0x252C (9516) bytes ACPI: RSDP 0x00007F0E8B380100 000024 (v02 Intel ) ACPI: XSDT 0x00007F0E8D2CDCB0 000034 (v00 Intel AcpiExec 00001001 INTL 20160729) ACPI: FACP 0x00007F0E8B37FF20 000114 (v05 Intel AcpiExec 00001001 INTL 20160729) ACPI: DSDT 0x00007F0E8D2CDEF0 00252C (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) ACPI: FACS 0x00007F0E8B3800C0 000040 Initializing General Purpose Events (GPEs): Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x0 (SCI) Initialized GPE 64 to 263 [_GPE] 64 regs on interrupt 0x0 (SCI) Initializing Namespace objects: Table [DSDT: BXPCDSDT] (id 01) - 292 Objects with 36 Devices, 9 Regions, 88 Methods (20/68/9 Serial/Non/Cvt) ACPI: 1 ACPI AML tables successfully acquired and loaded Completing Region/Field/Buffer/Package initialization: Initialized 9/9 Regions 0/0 Fields 40/40 Buffers 3/3 Packages (301 nodes) Initializing Device/Processor/Thermal objects and executing _INI/_STA methods: Executed 1 _INI methods requiring 0 _STA executions (examined 40 objects) - Caught a ctrl-c (#1) Thanks Jing Zhao Created attachment 1192842 [details]
guest dmesg log
Created attachment 1192854 [details]
ovmf log
The verification is all fine (= correctly performed and produced the right resutls), except for the acpidump / iasl check, which was not correctly performed. These are the right steps: acpidump -b iasl -d dsdt.dat The resultant file will be called "dsdt.dsl". Please upload "dsdt.dsl" to this BZ. We can then check the _CRS objects in it, as the last step for the verification. BTW, you can get "acpidump" from the "acpica-tools" package, no need to build it yourself. Thanks. Hi Updated the all test steps host kernel:3.10.0-496.el7.x86_64 qemu-kvm-rhev-2.6.0-20.el7.x86_64 1.Boot guest with following command /usr/libexec/qemu-kvm \ -M q35 \ -monitor stdio \ -vnc :20 \ -m 4G \ -vga std \ -smp 2,sockets=2,cores=1,threads=1 \ -object memory-backend-ram,size=2048M,id=ram-node0 \ -numa node,nodeid=0,cpus=0,memdev=ram-node0 \ -object memory-backend-ram,size=2048M,id=ram-node1 \ -numa node,nodeid=1,cpus=1,memdev=ram-node1 \ -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \ -serial unix:/tmp/serial0,server,nowait \ -debugcon file:/home/bug/ovmf.log \ -global isa-debugcon.iobase=0x402 \ -device pxb-pcie,id=bridge2,bus=pcie.0,numa_node=0,bus_nr=8 \ -device ioh3420,bus=bridge2,id=root.0,slot=1 \ -drive if=none,id=drive1,file=/home/bug/block.qcow2,format=qcow2 \ -device virtio-blk-pci,drive=drive1,scsi=off,bus=root.0 \ -device pxb-pcie,id=bridge3,bus=pcie.0,numa_node=1,bus_nr=40 \ -device ioh3420,bus=bridge3,id=root.1,slot=2 \ -drive if=none,id=drive0,file=/home/bug/ovmf.qcow2,format=qcow2 \ -device virtio-blk-pci,drive=drive0,scsi=off,bus=root.1,bootindex=1 \ -device ioh3420,id=root.2,slot=3 \ -device x3130-upstream,bus=root.2,id=upstream1 \ -device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \ -device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \ -device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \ -device virtio-net-pci,bus=downstream1,netdev=tap10,mac=9a:6a:6b:6c:6d:6e -netdev tap,id=tap10 \ 2.[root@localhost ~]# lspci -vvv -t -+-[0000:28]-+-00.0-[29]----00.0 Red Hat, Inc Virtio block device | \-01.0-[2a-2e]----00.0-[2b-2e]--+-00.0-[2c]----00.0 Red Hat, Inc Virtio network device | +-01.0-[2d]-- | \-02.0-[2e]-- +-[0000:08]---00.0-[09]----00.0 Red Hat, Inc Virtio block device \-[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Device 000b +-03.0 Red Hat, Inc. Device 000b +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller [root@localhost ~]# lspci 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:02.0 Host bridge: Red Hat, Inc. Device 000b 00:03.0 Host bridge: Red Hat, Inc. Device 000b 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 08:00.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 09:00.0 SCSI storage controller: Red Hat, Inc Virtio block device (rev 01) 28:00.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 28:01.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 0 (rev 02) 29:00.0 SCSI storage controller: Red Hat, Inc Virtio block device (rev 01) 2a:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Upstream) (rev 02) 2b:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2b:01.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2b:02.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (rev 01) 2c:00.0 Ethernet controller: Red Hat, Inc Virtio network device (rev 01) [root@localhost ~]# cat /sys/bus/pci/devices/0000\:09\:00.0/virtio2/features 0010101001110000000000000000110010000000000000000000000000000000 [root@localhost ~]# cat /sys/bus/pci/devices/0000\:29\:00.0/virtio0/features 0010101001110000000000000000110010000000000000000000000000000000 [root@localhost ~]# cat /sys/bus/pci/devices/0000\:2c\:00.0/virtio1/features 1100011111111111111101010000110010000000000000000000000000000000 3.Check the devices work well [root@localhost ~]# ping 10.66.4.211 PING 10.66.4.211 (10.66.4.211) 56(84) bytes of data. 64 bytes from 10.66.4.211: icmp_seq=1 ttl=64 time=0.951 ms 64 bytes from 10.66.4.211: icmp_seq=2 ttl=64 time=0.923 ms 64 bytes from 10.66.4.211: icmp_seq=3 ttl=64 time=0.923 ms ^C --- 10.66.4.211 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.923/0.932/0.951/0.028 ms [root@localhost ~]# dd if=/dev/zero of=/dev/vdb bs=1M count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 0.287967 s, 1.8 GB/s [root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 30G 0 disk ├─vda1 252:1 0 200M 0 part /boot/efi ├─vda2 252:2 0 1G 0 part /boot └─vda3 252:3 0 28.8G 0 part ├─rhel-root 253:0 0 26.8G 0 lvm / └─rhel-swap 253:1 0 2G 0 lvm [SWAP] vdb 252:16 0 1G 0 disk 4.check the iomem of guest [root@localhost ~]# cat /proc/iomem 00000000-00000fff : reserved 00001000-0009dfff : System RAM 0009e000-0009efff : reserved 0009f000-0009ffff : ACPI Non-volatile Storage 000a0000-000bffff : PCI Bus 0000:00 000f0000-000fffff : System ROM 00100000-7d86d017 : System RAM 02000000-0269afca : Kernel code 0269afcb-02af4aff : Kernel data 02ca1000-02fa2fff : Kernel bss 2d000000-370fffff : Crash kernel 7d86d018-7d88f857 : System RAM 7d88f858-7e16afff : System RAM 7e16b000-7e16bfff : ACPI Tables 7e16c000-7e16cfff : ACPI Non-volatile Storage 7e16d000-7e16f017 : System RAM 7e16f018-7e178657 : System RAM 7e178658-7e533fff : System RAM 7e534000-7e54ffff : reserved 7e550000-7e56ffff : System RAM 7e570000-7e590fff : reserved 7e591000-7e5cdfff : System RAM 7e5ce000-7e5ddfff : reserved 7e5de000-7e5edfff : ACPI Non-volatile Storage 7e5ee000-7f6a2fff : System RAM 7f6a3000-7f6fafff : reserved 7f6fb000-7f702fff : ACPI Tables 7f703000-7f706fff : ACPI Non-volatile Storage 7f707000-7f7cffff : System RAM 7f7d0000-7f7effff : reserved 7f7f0000-7f7fffff : System RAM 7f800000-8fffffff : reserved 80000000-8fffffff : PCI MMCONFIG 0000 [bus 00-ff] 90000000-911fffff : PCI Bus 0000:00 90000000-90ffffff : 0000:00:01.0 90000000-90ffffff : bochs-drm 91000000-91000fff : 0000:00:1f.2 91000000-91000fff : ahci 91001000-91001fff : 0000:00:01.0 91001000-91001fff : bochs-drm 91010000-9101ffff : 0000:00:01.0 91200000-913fffff : PCI Bus 0000:08 91200000-913fffff : PCI Bus 0000:09 91200000-91200fff : 0000:09:00.0 91200000-91200fff : virtio-pci 91400000-91bfffff : PCI Bus 0000:28 91400000-919fffff : PCI Bus 0000:2a 91400000-919fffff : PCI Bus 0000:2b 91400000-915fffff : PCI Bus 0000:2e 91600000-917fffff : PCI Bus 0000:2d 91800000-919fffff : PCI Bus 0000:2c 91800000-91800fff : 0000:2c:00.0 91800000-91800fff : virtio-pci 91840000-9187ffff : 0000:2c:00.0 91a00000-91bfffff : PCI Bus 0000:29 91a00000-91a00fff : 0000:29:00.0 91a00000-91a00fff : virtio-pci 91c00000-febfffff : PCI Bus 0000:00 fec00000-fec003ff : IOAPIC 0 fed1f410-fed1f414 : iTCO_wdt.0.auto fed1f410-fed1f414 : iTCO_wdt fee00000-fee00fff : Local APIC ffe00000-ffffffff : reserved 100000000-17fffffff : System RAM 800000000-8007fffff : PCI Bus 0000:08 800000000-8007fffff : PCI Bus 0000:09 800000000-8007fffff : 0000:09:00.0 800000000-8007fffff : virtio-pci 800800000-8017fffff : PCI Bus 0000:28 800800000-800ffffff : PCI Bus 0000:29 800800000-800ffffff : 0000:29:00.0 800800000-800ffffff : virtio-pci 801000000-8017fffff : PCI Bus 0000:2a 801000000-8017fffff : PCI Bus 0000:2b 801000000-8017fffff : PCI Bus 0000:2c 801000000-8017fffff : 0000:2c:00.0 801000000-8017fffff : virtio-pci And the ovmf log, please check the attachment 5.[root@localhost ~]# acpidump -b [root@localhost ~]# iasl -d dsdt.dat Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20160729-64 Copyright (c) 2000 - 2016 Intel Corporation Input file dsdt.dat, Length 0x252C (9516) bytes ACPI: DSDT 0x0000000000000000 00252C (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: dsdt.dsl - 99862 bytes and the dsdt.dsl, please check the attachment Lazslo, could you help to check the dsdt.dsl? Created attachment 1196162 [details]
the latest ovmf log
Created attachment 1196163 [details]
dstdt.dsl
Hi Laszlo Could you help to check the comment 15 ? Is it ok? Thanks very much * For the pxb-pcie device with bus_nr=8: - from the OVMF log: PciBus: Resource Map for Root Bridge PciRoot(0x8) Type = Io16; Base = 0x7000; Length = 0x1000; Alignment = 0xFFF Base = 0x7000; Length = 0x200; Alignment = 0xFFF; Owner = PPB [08|00|00:**] Type = Mem32; Base = 0x91200000; Length = 0x200000; Alignment = 0x1FFFFF Base = 0x91200000; Length = 0x200000; Alignment = 0x1FFFFF; Owner = PPB [08|00|00:**] Type = Mem64; Base = 0x800000000; Length = 0x800000; Alignment = 0x7FFFFF Base = 0x800000000; Length = 0x800000; Alignment = 0x7FFFFF; Owner = PPB [08|00|00:**]; Type = PMem64 - from the DSDT: Scope (\_SB) { Device (PC08) { ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x7000, // Range Minimum 0x7FFF, // Range Maximum 0x0000, // Translation Offset 0x1000, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0x91200000, // Range Minimum 0x913FFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00200000, // Length ,, , AddressRangeMemory, TypeStatic) QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x0000000000000000, // Granularity 0x0000000800000000, // Range Minimum 0x00000008007FFFFF, // Range Maximum 0x0000000000000000, // Translation Offset 0x0000000000800000, // Length ,, , AddressRangeMemory, TypeStatic) WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0008, // Range Minimum 0x0009, // Range Maximum 0x0000, // Translation Offset 0x0002, // Length ,, ) }) } } * For the pxb-pcie device with bus_nr=40: - from the OVMF log: PciBus: Resource Map for Root Bridge PciRoot(0x28) Type = Io16; Base = 0x8000; Length = 0x4000; Alignment = 0xFFF Base = 0x8000; Length = 0x3000; Alignment = 0xFFF; Owner = PPB [28|01|00:**] Base = 0xB000; Length = 0x200; Alignment = 0xFFF; Owner = PPB [28|00|00:**] Type = Mem32; Base = 0x91400000; Length = 0x800000; Alignment = 0x1FFFFF Base = 0x91400000; Length = 0x600000; Alignment = 0x1FFFFF; Owner = PPB [28|01|00:**] Base = 0x91A00000; Length = 0x200000; Alignment = 0x1FFFFF; Owner = PPB [28|00|00:**] Type = Mem64; Base = 0x800800000; Length = 0x1000000; Alignment = 0x7FFFFF Base = 0x800800000; Length = 0x800000; Alignment = 0x7FFFFF; Owner = PPB [28|00|00:**]; Type = PMem64 Base = 0x801000000; Length = 0x800000; Alignment = 0x7FFFFF; Owner = PPB [28|01|00:**]; Type = PMem64 - from the DSDT: Scope (\_SB) { Device (PC28) { ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x8000, // Range Minimum 0xBFFF, // Range Maximum 0x0000, // Translation Offset 0x4000, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0x91400000, // Range Minimum 0x91BFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00800000, // Length ,, , AddressRangeMemory, TypeStatic) QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x0000000000000000, // Granularity 0x0000000800800000, // Range Minimum 0x00000008017FFFFF, // Range Maximum 0x0000000000000000, // Translation Offset 0x0000000001000000, // Length ,, , AddressRangeMemory, TypeStatic) WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0028, // Range Minimum 0x002E, // Range Maximum 0x0000, // Translation Offset 0x0007, // Length ,, ) }) } } So yes, it is fine. Thanks. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2673.html |