Bug 1030839

Summary: invalid pci addr in info qtree when starting with -S
Product: [Fedora] Fedora Reporter: Lukáš Doktor <ldoktor>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: amit.shah, berrange, cfergeau, dwmw2, itamar, pbonzini, rjones, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-27 12:35:19 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:

Description Lukáš Doktor 2013-11-15 09:38:21 UTC
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 12:35:19 UTC
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 Lukáš Doktor 2013-11-27 14:12:19 UTC
OK, thank you, Paolo. I'm writing a test and this really confused me.