Bug 984341 - Disable or remove emulated device(pci-e switch/bridge) we will not support under -M i440fx
Summary: Disable or remove emulated device(pci-e switch/bridge) we will not support un...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Michael S. Tsirkin
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-15 01:50 UTC by juzhang
Modified: 2020-11-14 09:42 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-24 09:51:49 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description juzhang 2013-07-15 01:50:06 UTC
Description of problem:
KVM QE found that some device(pcie switch) can be used by using -M i440fx, however, these device are not supported it. From KVM QE POV,  Please Disable or remove emulated device(pci-e switch/bridge) we will not support under -M i440fx.


Version-Release number of selected component (if applicable):
Host Kernel
#uname -r
3.10.0-0.rc7.64.el7.x86_64
qemu-kvm version
qemu-kvm-1.5.1-2.el7.x86_64


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
#/usr/libexec/qemu-kvm -M pc-i440fx-rhel7.0.0 -device ? 2>&1 | grep -i stream
name "x3130-upstream", bus PCI, desc "TI X3130 Upstream Port of PCI Express Switch"
name "xio3130-downstream", bus PCI, desc "TI X3130 Downstream Port of PCI Express Switch"
#/usr/libexec/qemu-kvm -M pc-i440fx-rhel7.0.0 -device ? 2>&1 | grep -i ioh
name "ioh3420", bus PCI, desc "Intel IOH device id 3420 PCIE Root Port"

Expected results:
The device that supported with -M Q35 only should not be posted under -M pc-i440fx-rhel7.0.0.

Additional info:
From KVM QE POV, show to user or QE mean that we supported.

Comment 2 Michael S. Tsirkin 2013-07-15 15:40:30 UTC
-device ? is a global list and doesn't depend on -M.

So it will not be removed from there.
The issue is not a machine type in any case,
the issue is that these devices need a pcie bus
not a pci bus. So this is the bug:

name "x3130-upstream", bus PCI, desc "TI X3130 Upstream Port of PCI Express Switch"

should be "bus PCI-Express" or something like this.

Comment 3 Markus Armbruster 2013-08-26 12:45:38 UTC
Michael (comment#2) is correct: the list of device models available
with -device is fixed at compile-time, thus does not depend on the
machine type.

The only tool we have to restrict device plugging with -device and
device_add is buses: a device that needs to plug into a bus can only
be plugged if there is a bus that can take it.

As far as I can tell, upstream does not distinguish between PCI and
PCI-Express buses.  Perhaps they should be distinguished (I don't
know), but that's not what this bug is about.

This bug is about devices that are supported only in very specific
configurations.  The reporter's example is three optional parts of the
Q35 chipset (x3130-upstream, xio3130-downstream, ioh3420), which are
supported only with Q35 machine types, not with i440FX machine types.

If I understand Junyi correctly, QE wants us to make it impossible to
create these devices in unsupported configurations.

I'm not sure we can do that.  If we can't, we obviously must document
which devices may only be used in specific configurations, and how.

I understand QE needs that information sooner rather than later.

Junyi, is that a fair description of the bug's intent?

Comment 4 juzhang 2013-08-27 03:00:29 UTC
(In reply to Markus Armbruster from comment #3)
> Michael (comment#2) is correct: the list of device models available
> with -device is fixed at compile-time, thus does not depend on the
> machine type.
> 
> The only tool we have to restrict device plugging with -device and
> device_add is buses: a device that needs to plug into a bus can only
> be plugged if there is a bus that can take it.
> 
> As far as I can tell, upstream does not distinguish between PCI and
> PCI-Express buses.  Perhaps they should be distinguished (I don't
> know), but that's not what this bug is about.
> 
> This bug is about devices that are supported only in very specific
> configurations.  The reporter's example is three optional parts of the
> Q35 chipset (x3130-upstream, xio3130-downstream, ioh3420), which are
> supported only with Q35 machine types, not with i440FX machine types.
> 
> If I understand Junyi correctly, QE wants us to make it impossible to
> create these devices in unsupported configurations.
> 
> I'm not sure we can do that.  If we can't, we obviously must document
> which devices may only be used in specific configurations, and how.
> 
> I understand QE needs that information sooner rather than later.
> 
> Junyi, is that a fair description of the bug's intent?
Hi Markus,

You are totally right and thanks for your detailed explanations. About this issues, From QE POV, Please do 2 things at least.
1. name "x3130-upstream", bus PCI, desc "TI X3130 Upstream Port of PCI Express Switch".  should be "bus PCI-Express" or something like this. Mst mentioned in comment2.

2. Please document which devices may only be used in specific configurations, and how.

Thank you for creating so many bugs about "remove/disable devices which are not supported on RHEL7.0". It's very useful and clear for QE testing.

Best Regards,
Junyi

Comment 5 Markus Armbruster 2013-08-27 11:21:19 UTC
> 1. name "x3130-upstream", bus PCI, desc "TI X3130 Upstream Port of
> PCI Express Switch".  should be "bus PCI-Express" or something like
> this. Mst mentioned in comment2.

"bus FOO" part in the help text shows the qdev bus type name.  It
shows into what kind of bus this device can be plugged.

Currently, we don't fully separate PCI and PCI-Express in qdev.  PCI
buses can either of type PCI or PCIE, but devices can only have bus
type PCI, not PCIE.  A device with bus type PCI can plug into both PCI
and PCIE buses.  Unsurprisingly, this doesn't work when a device that
works only with one of them gets plugged into the other.

Naturally, you want to know which PCI devices can be plugged into
which kind(s) of PCI bus.  I suspect libvirt wants to know that, too.
As far as I can tell, this information isn't readily available, yet.
It needs to be made available to QE (human readable document is okay).
I suspect it also needs to be made available somehow via QOM, for
libvirt.

> 2. Please document which devices may only be used in specific
> configurations, and how.

Understood.

> Thank you for creating so many bugs about "remove/disable devices
> which are not supported on RHEL7.0". It's very useful and clear for
> QE testing.

Glad you find them helpful :)

Comment 6 Ronen Hod 2013-11-03 13:28:22 UTC
Deferring to 7.1.
This is part of an upstream debate regarding which device can be inserted to which slots (a mess when it comes to upstream/downstream PCI ports).

Comment 16 Eduardo Habkost 2017-01-18 13:05:33 UTC
The current work will allow querying the available buses/slots at runtime, but  the plans also include querying of available buses/slots on a machine-type before instantiating it.

Comment 18 Ademar Reis 2020-02-05 22:40:04 UTC
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 19 Michael S. Tsirkin 2020-09-24 09:51:49 UTC
-device ? is not a guarantee that the device can be created,
since this flag ignores the machine type.
not a bug.


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