Bug 1030839 - invalid pci addr in info qtree when starting with -S
invalid pci addr in info qtree when starting with -S
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 04:38 EST by Lukas Doktor
Modified: 2013-11-27 09:12 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-27 07:35:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lukas Doktor 2013-11-15 04:38:21 EST
Description of problem:
Hi guys, I noticed, that devices inside other PCI bus has incorrect long PCI addr (00:01.0 instead of 01:01.0) in "info qtree" when starting the VM in stopped state (-S). The address is correct when I remove the -S.

Version-Release number of selected component (if applicable):
qemu-kvm-1.4.2-11.fc19.x86_64
upstream qemu tag v1.7.0-rc0

How reproducible:
Always

Steps to Reproduce:
1. qemu-system-x86_64 -monitor stdio -device i82801b11-bridge,id=pci_bridge1,bus=pci.0 -device nec-usb-xhci,id=test_xhci1,addr=01,bus=pci_bridge1 -m 512 -enable-kvm -S
2. info qtree

Actual results:
The device test_xhci1's addr is 00:01.0 (when you boot the VM lspci shows 01:01.0)

Expected results:
The device test_xhci1's addr is 01:01.0 (the same as lspci shows)

Additional info:
When I remove the -S, the addr is correct.
Comment 1 Paolo Bonzini 2013-11-27 07:35:19 EST
PCI bridges are set up by the firmware.

Look here:

(qemu) info pci
  ...
  Bus  0, device   4, function 0:
    PCI bridge: PCI device 8086:244e
      BUS 0.
      secondary bus 0.
      subordinate bus 0.
      IO range [0x0000, 0x0fff]
      memory range [0x00000000, 0x000fffff]
      prefetchable memory range [0x00000000, 0x000fffff]
      id "pci_bridge1"
(qemu) cont
(qemu) stop
(qemu) info pci
  ...
  Bus  0, device   4, function 0:
    PCI bridge: PCI device 8086:244e
      BUS 0.
      secondary bus 1.
      subordinate bus 1.
      IO range [0xc000, 0xbfff]
      memory range [0xfea00000, 0xfeafffff]
      prefetchable memory range [0xfe000000, 0xfdffffff]
  Bus  1, device   1, function 0:
    USB controller: PCI device 1033:0194
      IRQ 10.
      BAR0: 64 bit memory at 0xfea00000 [0xfea03fff].
      id "test_xhci1"

After the bridge is set up, the USB controller device gets the right bus and appears in "info pci".  Until then, the data in "info qtree" is bogus.  If you're writing a testcase, I suggest you poll the QMP "query-pci" command until the USB controller appears.  It will be a sub-dictionary within the PCI bridge, like this:

  {
    "bus": 0,
    "slot": 4,
    "qdev_id": "pci_bridge1",
    "class_info": { "class": 1540, "desc": "PCI bridge" },
    "id": { "device": 9294, "vendor": 32902 },
    "function": 0, "regions": [],
    "pci_bridge": {
      "bus": {
        "prefetchable_range": { "limit": 4261412863, "base": 4261412864 },
        "memory_range": { "limit": 4272947199, "base": 4271898624 },
        "io_range": { "limit": 49151, "base": 49152 },
        "number": 0,
        "secondary": 1,
        "subordinate": 1
      },    
      "devices": [
        {     
          "bus": 1,
          "slot": 1,
          "qdev_id": "test_xhci1",
          "class_info": { "class": 3075, "desc": "USB controller" },
          "id": { "device": 404, "vendor": 4147 },
          "function": 0,
          "irq": 10,
          "regions": [
            {     
              "prefetch": false,
              "mem_type_64": true, 
              "bar": 0,
              "size": 16384,
              "address": 4271898624,
              "type": "memory"
            }     
          ]     
        }     
      ]     
    }
  }
Comment 2 Lukas Doktor 2013-11-27 09:12:19 EST
OK, thank you, Paolo. I'm writing a test and this really confused me.

Note You need to log in before you can comment on or make changes to this bug.