Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1358017 - [Q35] QEMU exposes extended config space of devices on non-PCI-express buses [NEEDINFO]
Summary: [Q35] QEMU exposes extended config space of devices on non-PCI-express buses
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michael S. Tsirkin
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-19 20:17 UTC by Alex Williamson
Modified: 2019-03-05 05:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
jinzhao: needinfo? (mst)


Attachments (Terms of Use)

Description Alex Williamson 2016-07-19 20:17:47 UTC
Description of problem:

Attach a device with PCI extended configuration space (such as an assigned PCIe device through vfio - but this is not a vfio bug) to a conventional PCI bus on a Q35 machine.  QEMU violates the PCIe spec allowing the extended configuration space to be visible to the VM.  This causes problems with things like SR-IOV capabilities where the QEMU vfio driver believes it only needs to hide the capability when the device is attached to an express bus.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Attach assigned device to a conventional bus on a q35 machine, such as the default location used by libvirt.
2.
3.

Actual results:
Note that lspci -vvv of the device in the guest lists capabilities at offsets 0x100 and above.  This violates the PCIe spec as any config access beyond the standard 256 bytes on a conventional bus should get an unsupported transaction response.

Expected results:
There should be no extended capabilities visible to the VM for devices placed on conventional buses.

Additional info:
440FX has no mechanism to access extended config space, this scenario can only be accomplished on Q35.

See: http://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg04378.html

This affects openstack users.

Comment 4 Laszlo Ersek 2018-08-12 15:11:05 UTC
Does this mean that the PCI Express capability (which lives in normal config space) should be, but is not, hidden as well?


(BTW, "docs/pcie.txt" says, "Plugging a PCI Express device into a PCI slot will hide the Extended Configuration Space [...]" -- so that is the desired behavior, but not a fact yet, right?) Thanks!

Comment 5 Laszlo Ersek 2018-08-12 15:12:47 UTC
(... a corollary question: on i440fx, should the PCI Express capability masked out of every Express device's normal config space?)

Comment 6 Alex Williamson 2018-08-13 04:24:26 UTC
(In reply to Laszlo Ersek from comment #4)
> Does this mean that the PCI Express capability (which lives in normal config
> space) should be, but is not, hidden as well?
> 
> 
> (BTW, "docs/pcie.txt" says, "Plugging a PCI Express device into a PCI slot
> will hide the Extended Configuration Space [...]" -- so that is the desired
> behavior, but not a fact yet, right?) Thanks!

(In reply to Laszlo Ersek from comment #5)
> (... a corollary question: on i440fx, should the PCI Express capability
> masked out of every Express device's normal config space?)

What we've found in vfio-pci is that the guest OS mostly only cares about the PCIe capability when the machine type is PCIe capable.  Therefore when we find a device with a PCIe capability on a non-express bus, we search up to the root complex to check whether that root bus is express, if it is we drop the PCIe capability, if not we leave it.  Thus our 440fx approach is basically, if it's not broken, don't fix it.

Comment 7 jingzhao 2019-03-05 05:20:25 UTC
Hi mst

  1. do we plan to fix it on rhel7.7?
  2. The assigned device will be plug into conventional bus on a q35 machine, the conventional bus is "pcie-pci-bridge" or "pcie.0", and any other conventional bus?
  3. the obviously result about this issue: will get offsets 0x100 through lspci -vvv *the assigned device*, am I right?

Thanks
Jing


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