libvirt previously assigned nearly all devices to a hotpluggable
legacy PCI slot even on machines with a PCIe root complex. Doing this
means that the domain will need a dmi-to-pci-bridge (to convert from
PCIe to legacy PCI) and a pci-bridge (to provide hotpluggable legacy
PCI slots.
To help
Due to its unpopularity, I've removed the "hotpluggable" attribute
that was in V1 of this patchset, and also auto-assign *all* devices
(except primary video and USB2 for historical reasons) to hotpluggable
slots only (rather than assigning devices to the non-hotpluggable
pcie-root if libvirt
The nec-usb-xhci device (which is a USB3 controller) has always
presented itself as a PCI device when plugged into a legacy PCI slot,
and a PCIe device when plugged into a PCIe slot, but libvirt has
always auto-assigned it to a PCI slot.
This patch changes that behavior to auto-assign to a PCIe
A pci-bridge has *almost* the same rules as a legacy PCI endpoint
device for where it can be automatically connected, and until now both
had been considered identical. There is one pairing that is okay when
specifically requested by the user (i.e. manual assignment), but we
want to avoid it when
The e1000e is an emulated network device based on the Intel 82574,
present in qemu 2.7.0 and later. Among other differences from the
e1000, it presents itself as a PCIe device rather than legacy PCI. In
order to get it assigned to a PCIe controller, this patch updates the
flags setting for network
The 'multi' element in PCI address struct used as 'virTristateSwitch',
and its default value is 'VIR_TRISTATE_SWITCH_ABSENT'. Current PCI
process use 'false' to initialization 'multi', which is ambiguously
for assignment or comparison. This patch use '{0}' to initialize
the whole PCI address
Commit 11567cf added some libxl tests into domaincapstest and
added libvirt_driver_libxl_impl.la to domaincapstest_LDADD.
This causes link fail on systems without GNU regex implementation:
gmake[2]: Entering directory '/usr/home/novel/code/libvirt/tests'
CCLD domaincapstest
On Sat, 2016-08-13 at 21:09 +0200, Martin Kletzander wrote:
> > My interpretation was that Andrea is suggesting two things:
> >
> > 1) remove any code within libvirt that maintains compatibility when a
> > contemporary libvirtd (or application using contemporary libvirt client
> > library) is
On Fri, Aug 12, 2016 at 06:25:16PM +0200, Andrea Bolognani wrote:
> A while ago, we agreed to drop support for QEMU versions older
> than 0.12.0, with the rationale that we should focus on
> operating systems that are still supported by the respective
> vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and
