RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1323976 - PCI: Add 64-bit MMIO support to PXB devices
Summary: PCI: Add 64-bit MMIO support to PXB devices
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.2
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Marcel Apfelbaum
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-05 08:51 UTC by Marcel Apfelbaum
Modified: 2016-11-07 21:04 UTC (History)
10 users (show)

Fixed In Version: qemu-kvm-rhev-2.6.0-19.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-07 21:04:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
guest dmesg log (54.48 KB, text/plain)
2016-08-22 09:06 UTC, jingzhao 		no flags Details
ovmf log (111.74 KB, text/plain)
2016-08-22 09:06 UTC, jingzhao 		no flags Details
the latest ovmf log (137.33 KB, text/plain)
2016-08-31 04:49 UTC, jingzhao 		no flags Details
dstdt.dsl (97.52 KB, text/x-csrc)
2016-08-31 04:50 UTC, jingzhao 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 0 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Marcel Apfelbaum 2016-04-05 08:51:05 UTC 
Description of problem:

The calculation & merging of the PXB memory ranges already happens in
64-bit, but the entry boundaries are silently truncated to 32-bit.

We also can't assign all the [pci->w64.begin, pci->w64.end - 1] range to bus
0 anymore, we need to take out the ranges used by PXBs. (same as we did
for pci->w32).
Comment 1 Marcel Apfelbaum 2016-04-05 08:55:23 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.
Comment 2 Marcel Apfelbaum 2016-05-10 16:28:22 UTC 
Patches posted upstream:
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg00090.html
Comment 3 Laszlo Ersek 2016-06-15 11:11:13 UTC 
Marcel's v2 upstream series:
http://thread.gmane.org/gmane.comp.emulators.qemu/411649
Comment 4 jingzhao 2016-08-01 05:46:40 UTC 
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
Comment 5 Laszlo Ersek 2016-08-01 15:37:46 UTC 
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.)
Comment 6 Marcel Apfelbaum 2016-08-01 17:00:40 UTC 
(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
Comment 7 Miroslav Rezanina 2016-08-05 10:56:28 UTC 
Fix included in qemu-kvm-rhev-2.6.0-19.el7
Comment 9 jingzhao 2016-08-22 09:01:02 UTC 
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
Comment 10 jingzhao 2016-08-22 09:06:03 UTC 
Created attachment 1192842 [details]
guest dmesg log
Comment 11 jingzhao 2016-08-22 09:06:43 UTC 
Created attachment 1192854 [details]
ovmf log
Comment 12 Laszlo Ersek 2016-08-30 15:24:12 UTC 
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.
Comment 13 jingzhao 2016-08-31 04:44:38 UTC 
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?
Comment 14 jingzhao 2016-08-31 04:49:33 UTC 
Created attachment 1196162 [details]
the latest ovmf log
Comment 15 jingzhao 2016-08-31 04:50:09 UTC 
Created attachment 1196163 [details]
dstdt.dsl
Comment 16 jingzhao 2016-08-31 04:53:40 UTC 
Hi Laszlo

  Could you help to check the comment 15 ? Is it ok?

Thanks very much
Comment 17 Laszlo Ersek 2016-08-31 15:57:05 UTC 
* 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.
Comment 18 jingzhao 2016-09-01 00:45:20 UTC 
According to Comment13 and comment17, the bz can make as verified

Thanks
Jing Zhao
Comment 20 errata-xmlrpc 2016-11-07 21:04:06 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.