Commit Graph

7 Commits

Author SHA1 Message Date
Cole Robinson
56540950e7 qemu: command: always use -chardev for monitor config
AFAIK there aren't any cases where we will/should hit the old code
path for our supported qemu versions, so drop the old code.

Massive test suite churn follows

Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
2017-07-10 16:59:38 -04:00
Pavel Hrdina
e6e26a899d tests: unify qemu binary paths for all qemu related tests
Our test data used a lot of different qemu binary paths and some
of them were based on downstream systems.

Note that there is one file where I had to add "accel=kvm" because
the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm".

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-11 14:06:47 +02:00
Laine Stump
70d15c9ac6 qemu: initially reserve one open pcie-root-port for hotplug
For machinetypes with a pci-root bus (all legacy PCI), libvirt will
make a "fake" reservation for one extra slot prior to assigning
addresses to unaddressed PCI endpoint devices in the domain. This will
trigger auto-adding of a pci-bridge for the final device to be
assigned an address *if that device would have otherwise instead been
the last device on the last available pci-bridge*; thus it assures
that there will always be at least one slot left open in the domain's
bus topology for expansion (which is important both for hotplug (since
a new pci-bridge can't be added while the guest is running) as well as
for offline additions to the config (since adding a new device might
otherwise in some cases require re-addressing existing devices, which
we want to avoid)).

It's important to note that for the above case (legacy PCI), we must
check for the special case of all slots on all buses being occupied
*prior to assigning any addresses*, and avoid attempting to reserve
the extra address in that case, because there is no free address in
the existing topology, so no place to auto-add a pci-bridge for
expansion (i.e. it would always fail anyway). Since that condition can
only be reached by manual intervention, this is acceptable.

For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's
methodology for automatically expanding the bus topology is different
- pcie-root-ports are plugged into slots (soon to be functions) of
pcie-root as needed, and the new endpoint devices are assigned to the
single slot in each pcie-root-port. This is done so that the devices
are, by default, hotpluggable (the slots of pcie-root don't support
hotplug, but the single slot of the pcie-root-port does). Since
pcie-root-ports can only be plugged into pcie-root, and we don't
auto-assign endpoint devices to the pcie-root slots, this means
topology expansion doesn't compete with endpoint devices for slots, so
we don't need to worry about checking for all "useful" slots being
free *prior* to assigning addresses to new endpoint devices - as a
matter of fact, if we attempt to reserve the open slots before the
used slots, it can lead to errors.

Instead this patch just reserves one slot for a "future potential"
PCIe device after doing the assignment for actual devices, but only
if the only PCI controller defined prior to starting address
assignment was pcie-root, and only if we auto-added at least one PCI
controller during address assignment. This assures two things:

1) that reserving the open slots will only be done when the domain is
   initially defined, never at any time after, and

2) that if the user understands enough about PCI controllers that they
   are adding them manually, that we don't mess up their plan by
   adding extras - if they know enough to add one pcie-root-port, or
   to manually assign addresses such that no pcie-root-ports are
   needed, they know enough to add extra pcie-root-ports if they want
   them (this could be called the "libguestfs clause", since
   libguestfs needs to be able to create domains with as few
   devices/controllers as possible).

This is set to reserve a single free port for now, but could be
increased in the future if public sentiment goes in that direction
(it's easy to increase later, but essentially impossible to decrease)
2016-11-14 14:23:48 -05:00
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
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
Martin Kletzander
a89f05ba8d qemu: Shorten per-domain directory names
Per-domain directories were introduced in order to be able to
completely separate security labels for each domain (commit
f1f68ca334).  However when the domain
name is long (let's say a ridiculous 110 characters), we cannot
connect to the monitor socket because on length of UNIX socket address
is limited.  In order to get around this, let's shorten it in similar
fashion and in order to avoid conflicts, throw in an ID there as well.
Also save that into the status XML and load the old status XMLs
properly (to clean up after older domains).  That way we can change it
in the future.

The shortening can be seen in qemuxml2argv tests, for example in the
hugepages-pages2 case.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-03-01 07:15:29 +01:00
Cole Robinson
fde937bda0 qemu: command: wire up usage of q35/ich9 disable s3/s4
If the q35 specific disable s3/s4 setting isn't supported, fallback to
specifying the PIIX setting, which is the previous behavior. It doesn't
have any effect, but qemu will just warn about it rather than error:

  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s3=1 not used
  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s4=1 not used

Since it doesn't error, I don't think we should either, since there
may be configs in the wild that already have q35 + disable_s3/4 (via
virt-manager)
2016-01-10 15:16:38 -05:00