Bug 1527882 - [RFE] Q35: Use 16 PCI Express Root Ports as a system-wide configuration in RHV-M
Summary: [RFE] Q35: Use 16 PCI Express Root Ports as a system-wide configuration in RHV-M
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.3.2
: 4.3.0
Assignee: Shmuel Melamud
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On:
Blocks: 1527843
TreeView+ depends on / blocked
 
Reported: 2017-12-20 10:39 UTC by Marcel Apfelbaum
Modified: 2019-05-08 12:37 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.3.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-08 12:36:59 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:
nsimsolo: testing_plan_complete+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1085 0 None None None 2019-05-08 12:37:22 UTC
oVirt gerrit 96863 0 master MERGED core: Create 16 PCI-E ports for Q35 2020-07-21 15:39:20 UTC

Description Marcel Apfelbaum 2017-12-20 10:39:25 UTC
Currently we will have a single unused
pcie-root-port available for hotplugging devices
If you need more than that, you will need to modify the
domain definition a 2nd time to add more lines like:

    <controller type='pci' model='pcie-root-port'/>

(all the other parameters are automatically set). If you're doing this
during initial domain definition, or at the same time you add new
devices, you'll need to add an *additional* pcie-root-port for each PCI
device you're adding.


In order to to avoid the above, use 16 PCI Express Root Ports on the
default configuration that can be used either by devices present at
domain creation time or for hot plug.
When we are out of port we cannot add devices anymore, like in real HW.

Comment 1 Ryan Barry 2019-01-21 14:53:54 UTC
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Comment 3 Sandro Bonazzola 2019-02-01 14:52:01 UTC
Not blocking ovirt-4.3.0 on this. Moving to 4.3.1.

Comment 5 RHV bug bot 2019-02-21 17:26:03 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 6 Nisim Simsolo 2019-03-05 12:14:00 UTC
Verification builds: 
ovirt-engine-4.3.1.2-0.0.master.20190301101852.gita03a284.el7
qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
vdsm-4.40.0-27.git8414ae9.el7.x86_64
libvirt-client-4.5.0-10.el7_6.4.x86_64

Verification scenario: 
1. Create and run the next Linux VMs (RHEL7, Ubuntu and Debian):
- Q35 chipset with UEFI BIOS
- Q35 chipset with SecureBoot
- Q35 chipset with legacy BIOS
Verify each VM is running with 16 QEMU PCIe Root port. for example: 

[nsimsolo@localhost ~]$ lspci | grep -i pci 
00:02.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.3 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.4 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.5 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.6 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:02.7 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.3 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.4 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.5 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.6 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
00:03.7 PCI bridge: Red Hat, Inc. QEMU PCIe Root port
[nsimsolo@localhost ~]$ 

2. Repeat test for different Windows OS types (PCIe devices can be observed from Windows device manager -> system devices).

Comment 8 errata-xmlrpc 2019-05-08 12:36:59 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://access.redhat.com/errata/RHEA-2019:1085


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