Commit Graph

6 Commits

Author SHA1 Message Date
Peter Krempa
e114b09157 qemu: caps: Always assume QEMU_CAPS_SMP_TOPOLOGY
Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50
prior to 0.12.0, our minimum supported qemu version.

$ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62
v0.11.0-rc0-449-gdc6b1c0
$ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab
v0.12.0-rc0~1477
2016-07-07 15:08:35 +02:00
Andrea Bolognani
dc5821d743 qemu: Don't use legacy USB for aarch64 mach-virt guests
The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.

However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.

Avoid it completely, like it's already happening for q35.
2016-06-20 09:58:48 +02:00
Andrea Bolognani
86a68bdb0c qemu: Permit PCI-free aarch64 mach-virt guests
There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.

Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.
2016-06-17 18:30:04 +02:00
Laine Stump
d5fb8f4564 qemu: don't add pci-bridge to Q35/arm domains unless it's needed
Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).

This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.
2016-06-16 13:48:25 -04:00
Laine Stump
0d668434f4 conf: allow use of slot 0 in a dmi-to-pci-bridge
When support for dmi-to-pci-bridge was added, it was assumed that,
just as with the pci-root bus, slot 0 was reserved. This is not the
case - it can be used to connect a device just like any other slot, so
remove the restriction and update the test cases that auto-assign an
address on a dmi-to-pci-bridge.
2016-04-14 14:00:33 -04:00
Ján Tomko
f06ca25d23 qemu: support virt-2.6 machine type on arm
Some places already check for "virt-" prefix as well as plain "virt".
virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices
having assigned the same unnumbered "pci" alias.

Add a test for the "virt-2.6" machine type which also omits the
<model type='virtio'/> in <interface>, to check if
qemuDomainDefaultNetModel works too.

https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 14:15:51 +02:00