Bug 1504111

Summary: pcie: disable IO ports by default for Generic PCIe Root Ports
Product: Red Hat Enterprise Linux 7 Reporter: Marcel Apfelbaum <marcel>
Component: libvirtAssignee: Andrea Bolognani <abologna>
Status: CLOSED DUPLICATE QA Contact: Han Han <hhan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.5CC: berrange, dyuan, jsuchane, lmen, rbalakri, xuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-15 14:41:50 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:
Embargoed:

Description Marcel Apfelbaum 2017-10-19 13:56:49 UTC
The IO range space is pretty limited and each PCIe port is actually a PCI bridge consuming 4K IO range even if devices behind it are PCIe and do not require IO Ports at all.

QEMU's Generic PCIe Root Port has a new property called io-reserve and setting it to 0 does the trick:
   -device pice-root-port,io-reserve=0

Libvirt should set io-reserve=0 by default for all ports expect ports used or planned to be used with the new pcie-pci bridge that allows using PCI devices on a PCIe machine.

Comment 2 Daniel Berrangé 2017-10-19 14:04:12 UTC
Libvirt can't just add  io-reserve=0 onto ports by default at this point, because it would be a machine ABI change that would break migration compatibility for all previously deployed guests.

Comment 3 Marcel Apfelbaum 2017-10-19 14:18:18 UTC
(In reply to Daniel Berrange from comment #2)
> Libvirt can't just add  io-reserve=0 onto ports by default at this point,
> because it would be a machine ABI change that would break migration
> compatibility for all previously deployed guests.

What about for all the new xml domains?

Comment 4 Jaroslav Suchanek 2017-11-15 14:41:50 UTC
I believe this is a dup of bug 1408810. Please reopen this one if I am mistaken. Thanks.

*** This bug has been marked as a duplicate of bug 1408810 ***