Commit Graph

820 Commits

Author SHA1 Message Date
John Ferlan
1ff38366b8 qemu: Add the group name option to the iotune command line
Add in the block I/O throttling group parameter to the command line
if supported. If not supported, fail command creation.

Add the xml2argvtest for testing.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-05 18:30:38 -05:00
John Ferlan
32d99cb772 conf: Add support for blkiotune group_name option
Modify _virDomainBlockIoTuneInfo and rng schema to support the group_name
option for iotune throttling. Document the new value.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-05 18:30:34 -05:00
Marc Hartmayer
36d9965af0 tests: add test cases for address conflicts
Add test cases for address conflicts between disks and hostdevs that are
using drive addresses.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-12-05 10:45:46 +01:00
Marc Hartmayer
b39d3a7eb6 tests: don't use duplicate disk addresses
Don't use duplicate disk addresses in test cases unless it's useful. At
least the test case will break once we have a check for uniqueness of
addresses at time of domain definition.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
2016-12-05 10:45:46 +01:00
Ján Tomko
2650d5e1f5 qemu: error out on USB ports out of range
My overly sophisticated address reservation code forgot
to add an error message for user-requested ports out of range.

https://bugzilla.redhat.com/show_bug.cgi?id=1399260
2016-11-30 10:59:01 +01:00
Ján Tomko
a101588921 tests: Fix USB ports in usb-redir-filter
This test case references ports 4 and 5 on the PIIX3 UHCI
controller which only has two.
2016-11-30 10:59:01 +01:00
Eric Farman
ae5d30a0b3 conf: Wire up the vhost-scsi connection from/to XML
With the QEMU components in place, provide the XML parsing to
invoke that code when given the following XML snippet:

    <hostdev mode='subsystem' type='scsi_host'>
      <source protocol='vhost' wwpn='naa.501234567890abcd'/>
    </hostdev>

An optional address element can be specified within the hostdev
(pick CCW or PCI as necessary):

    <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0625'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

Add basic vhost-scsi tests which were cloned from hostdev-scsi-virtio-scsi
in both xml2argv and xml2xml. Added ones for both vhost-scsi-ccw and
vhost-scsi-pci since the syntaxes are slightly different between them.

Also adjusted the docs to describe the changes.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-11-24 12:22:25 -05: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
Laine Stump
8d873a5a47 qemu: try to put ich9 sound device at 00:1B.0
Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This patch does the same for the ich9 "HD audio"
device.

The main inspiration for this patch is that currently the *only*
device in a reasonable "workstation" type virtual machine config that
requires a legacy PCI slot is the audio device, Without this patch,
the standard Q35 machine created by virt-manager will have a
dmi-to-pci-bridge and a pci-bridge just for the sound device; with the
patch (and if you change the sound device model from the default
"ich6" to "ich9"), the machine definition constructed by virt-manager
has absolutely no legacy PCI controllers - any legacy PCI devices
(e.g. video and sound) are on pcie-root as integrated devices.
2016-11-14 14:23:01 -05:00
Laine Stump
d8bd837669 qemu: add a USB3 controller to Q35 domains by default
Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinetypes to add an XHCI instead (if it's
supported, which it of course *will* be).

Since none of the existing test cases left out USB controllers in the
input XML, a new Q35 test case was added which has *no* devices, so
ends up with only the defaults always put in by qemu, plus those added
by libvirt.
2016-11-14 14:22:23 -05:00
Laine Stump
807232203a qemu: don't force-add a dmi-to-pci-bridge just on principle
Now the a dmi-to-pci-bridge is automatically added just as it's needed
(when a pci-bridge is being added), we no longer have any need to
force-add one to every single Q35 domain.
2016-11-14 14:21:43 -05:00
Laine Stump
815b51d97a qemu: update tests to not assume dmi-to-pci-bridge is always added
A few of the qemu test cases assume that a dmi-to-pci-bridge will
always be added at index 1, and so they omit it from the input data
even though a pci-bridge is present at index 2, e.g.:

   <controller type='pci' index='0' model='pcie-root'/>
   <controller type='pci' index='2' model='pci-bridge'/>

Support for this odd practice was discussed on libvir-list and we
decided that the complex code required to make this continue was not
worth the headache of maintaining. So instead, this patch modifies the
test cases to manually add a dmi-to-pci-bridge at index 1 (since an
upcoming patch is going to eliminate the unconditional adding of
dmi-to-pci-bridge).

Because the auto-add was placing the dmi-to-pci-bridge later in the
list (even though it has a lower index) the test output is also
updated to take account for the new order (which puts the pci
controllers in index-order)
2016-11-14 14:21:15 -05:00
Laine Stump
0702f48ef4 qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed
Previously libvirt would only add pci-bridge devices automatically
when an address was requested for a device that required a legacy PCI
slot and none was available. This patch expands that support to
dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a
machine with a pcie-root), and pcie-root-port (which is needed to add
a hotpluggable PCIe device). It does *not* automatically add
pcie-switch-upstream-ports or pcie-switch-downstream-ports (and
currently there are no plans for that).

Given the existing code to auto-add pci-bridge devices, automatically
adding pcie-root-ports is fairly straightforward. The
dmi-to-pci-bridge support is a bit tricky though, for a few reasons:

1) Although the only reason to add a dmi-to-pci-bridge is so that
   there is a reasonable place to plug in a pci-bridge controller,
   most of the time it's not the presence of a pci-bridge *in the
   config* that triggers the requirement to add a dmi-to-pci-bridge.
   Rather, it is the presence of a legacy-PCI device in the config,
   which triggers auto-add of a pci-bridge, which triggers auto-add of
   a dmi-to-pci-bridge (this is handled in
   virDomainPCIAddressSetGrow() - if there's a request to add a
   pci-bridge we'll check if there is a suitable bus to plug it into;
   if not, we first add a dmi-to-pci-bridge).

2) Once there is already a single dmi-to-pci-bridge on the system,
   there won't be a need for any more, even if it's full, as long as
   there is a pci-bridge with an open slot - you can also plug
   pci-bridges into existing pci-bridges. So we have to make sure we
   don't add a dmi-to-pci-bridge unless there aren't any
   dmi-to-pci-bridges *or* any pci-bridges.

3) Although it is strongly discouraged, it is legal for a pci-bridge
   to be directly plugged into pcie-root, and we don't want to
   auto-add a dmi-to-pci-bridge if there is already a pci-bridge
   that's been forced directly into pcie-root.

Although libvirt will now automatically create a dmi-to-pci-bridge
when it's needed, the code still remains for now that forces a
dmi-to-pci-bridge on all domains with pcie-root (in
qemuDomainDefAddDefaultDevices()). That will be removed in a future
patch.

For now, the pcie-root-ports are added one to a slot, which is a bit
wasteful and means it will fail after 31 total PCIe devices (30 if
there are also some PCI devices), but helps keep the changeset down
for this patch. A future patch will have 8 pcie-root-ports sharing the
functions on a single slot.
2016-11-14 14:19:36 -05:00
Laine Stump
5266426b21 qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate
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 legacy PCI slot.

This patch changes that behavior to auto-assign to a PCIe slot on
systems that have pcie-root (e.g. Q35 and aarch64/virt).

Since we don't yet auto-create pcie-*-port controllers on demand, this
means a config with an nec-xhci USB controller that has no PCI address
assigned will also need to have an otherwise-unused pcie-*-port
controller specified:

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

(this assumes there is an otherwise-unused slot on pcie-root to accept
the pcie-root-port)
2016-11-14 14:18:06 -05:00
Laine Stump
9dfe733e99 qemu: assign e1000e network devices to PCIe slots when appropriate
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 devices when the model name is "e1000e".

(Note that for some reason libvirt has never validated the network
device model names other than to check that there are no dangerous
characters in them. That should probably change, but is the subject of
another patch.)

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1343094
2016-11-14 14:17:14 -05:00
Laine Stump
c7fc151eec qemu: assign virtio devices to PCIe slot when appropriate
libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy PCI slots!)
Forcing all devices onto legacy PCI slots 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 which, again,
usually aren't hotpluggable anyway).

To help reduce the need for these legacy controllers, this patch tries
to assign virtio-1.0-capable devices to PCIe slots whenever possible,
by setting appropriate connectFlags in
virDomainCalculateDevicePCIConnectFlags(). Happily, when that function
was written (just a few commits ago) it was created with a
"virtioFlags" argument, set by both of its callers, which is the
proper connectFlags to set for any virtio-*-pci device - depending on
the arch/machinetype of the domain, and whether or not the qemu binary
supports virtio-1.0, that flag will have either been set to PCI or
PCIe. This patch merely enables the functionality by setting the flags
for the device to whatever is in virtioFlags if the device is a
virtio-*-pci device.

NB: the first virtio video device will be placed directly on bus 0
slot 1 rather than on a pcie-root-port due to the override for primary
video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not
to change that is a topic of discussion, but this patch doesn't change
that particular behavior.

NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root
complex) does *not* support hotplug, this means that suitable
controllers must also be in the config (i.e. either pcie-root-port, or
pcie-downstream-port). For now, libvirt doesn't add those
automatically, so if you put virtio devices in a config for a qemu
that has PCIe-capable virtio devices, you'll need to add extra
pcie-root-ports yourself. That requirement will be eliminated in a
future patch, but for now, it's simple to do this:

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

Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
2016-11-14 14:16:12 -05:00
Peter Krempa
b7798a07f9 qemu: Generate memory device aliases according to slot number
The memory device alias needs to be treated as machine ABI as qemu is
using it in the migration stream for section labels. To simplify this
generate the alias from the slot number unless an existing broken
configuration is detected.

With this patch the aliases are predictable and even certain
configurations which would not be migratable previously are fixed.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1359135
2016-11-10 17:36:55 +01:00
Peter Krempa
ce1ee02a25 qemu: Assign slots to memory devices prior to usage
As with other devices assign the slot number right away when adding the
device. This will make the slot numbers static as we do with other
addressing elements and it will ultimately simplify allocation of the
alias in a static way which does not break with qemu.
2016-11-10 17:36:55 +01:00
Peter Krempa
810e9a8061 conf: Allow specifying only the slot number for hotpluggable memory
Simplify handling of the 'dimm' address element by allowing to specify
the slot number only. This will allow libvirt to allocate slot numbers
before starting qemu.
2016-11-10 17:36:55 +01:00
Martin Kletzander
5672a265ce qemu: Make sure shmem memory is shared
Even though using /dev/shm/asdf as the backend, we still need to make
the mapping shared.  The original patch forgot to add that parameter.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1392031

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-10 08:31:19 +01:00
Prasanna Kumar Kalever
e66603539b qemu: command: Add debug option for gluster volumes
Propagate the selected or default level to qemu if it's supported.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1376009

Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2016-11-09 16:52:40 +01:00
Martin Kletzander
06524fd52c qemu: Support newer ivshmem device variants
QEMU added support for ivshmem-plain and ivshmem-doorbell.  Those are
reworked varians of legacy ivshmem that are compatible from the guest
POV, but not from host's POV and have sane specification and handling.

Details about the newer device type can be found in qemu's commit
5400c02b90bb:

  http://git.qemu.org/?p=qemu.git;a=commit;h=5400c02b90bb

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-02 17:36:17 +01:00
Martin Kletzander
acf0ec024a qemu: Save various defaults for shmem
We're keeping some things at default and that's not something we want to
do intentionally.  Let's save some sensible defaults upfront in order to
avoid having problems later.  The details for the defaults (of the newer
implementation) can be found in qemu's commit 5400c02b90bb:

  http://git.qemu.org/?p=qemu.git;a=commit;h=5400c02b90bb

Since we are merely saving the defaults it will not change the guest ABI
and thanks to the fact that we're doing it in the PostParse callback it
will not break the ABI stability checks.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-02 16:05:39 +01:00
Martin Kletzander
3c06aa7b30 conf, qemu: Add newer shmem models
The old ivshmem is deprecated in QEMU, so let's use the better
ivshmem-{plain,doorbell} variants instead.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-02 16:05:39 +01:00
Martin Kletzander
64530a9c66 conf, qemu: Add support for shmem model
Just the default one now, new ones will be added in following commits.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-02 16:05:39 +01:00
Gema Gomez
0701abcb3b qemu: Add support for using AES secret for SCSI hotplug
Support for virtio disks was added in commit id 'fceeeda', but not for
SCSI drives. Add the secret for the server when hotplugging a SCSI drive.
No need to make any adjustments for unplug since that's handled during
the qemuDomainDetachDiskDevice call to qemuDomainRemoveDiskDevice in
the qemuDomainDetachDeviceDiskLive switch.

Added a test to/for the command line processing to show the command line
options when adding a SCSI drive for the guest.
2016-10-26 08:07:15 -04:00
John Ferlan
daf5c651f0 qemu: Add a secret object to/for a char source dev
Add the secret object so the 'passwordid=' can be added if the command line
if there's a secret defined in/on the host for TCP chardev TLS objects.

Preparation for the secret involves adding the secinfo to the char source
device prior to command line processing. There are multiple possibilities
for TCP chardev source backend usage.

Add test for at least a serial chardev as an example.
2016-10-26 07:18:25 -04:00
John Ferlan
2db108c766 qemu: Add the length options to the iotune command line
Add in the block I/O throttling length/duration parameter to the command
line if supported. If not supported, fail command creation.

Add the xml2argvtest for testing.
2016-10-25 17:20:17 -04:00
John Ferlan
8dcf355973 conf: Add support for blkiotune "_length" options
Modify _virDomainBlockIoTuneInfo and rng schema to support the _length
options for bps/iops throttling values. Document the new values.
2016-10-25 17:20:17 -04:00
Pavel Hrdina
0298531b29 domain: Add optional 'tls' attribute for TCP chardev
Add an optional "tls='yes|no'" attribute for a TCP chardev.

For QEMU, this will allow for disabling the host config setting of the
'chardev_tls' for a domain chardev channel by setting the value to "no" or
to attempt to use a host TLS environment when setting the value to "yes"
when the host config 'chardev_tls' setting is disabled, but a TLS environment
is configured via either the host config 'chardev_tls_x509_cert_dir' or
'default_tls_x509_cert_dir'

Signed-off-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-24 16:05:33 +02:00
Pavel Hrdina
df93b5f5f5 qemu: always generate the same alias for tls-creds-x509 object
There was inconsistency between alias used to create tls-creds-x509
object and alias used to link that object to chardev while hotpluging.
Hotplug ends with this error:

  error: Failed to detach device from channel-tcp.xml
  error: internal error: unable to execute QEMU command 'chardev-add':
  No TLS credentials with id 'objcharchannel3_tls0'

In XML we have for example alias "serial0", but on qemu command line we
generate "charserial0".

The issue was that code, that creates QMP command to hotplug chardev
devices uses only the second alias "charserial0" and that alias is also
used to link the tls-creds-x509 object.

This patch unifies the aliases for tls-creds-x509 to be always generated
from "charserial0".

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-18 17:01:26 +02:00
John Ferlan
40b6f91900 qemu: Add 'verify-peer=yes' test for chardev TCP TLS
Missing the option to set verify-peer to yes

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-10-17 15:38:32 -04:00
Andrea Bolognani
61e101437b conf: Explain some code in more detail
The code is entirely correct, but it still managed to trip me
up when I first ran into it because I did not realize right away
that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but
rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and
VIR_PCI_CONNECT_TYPE_PCIE_DEVICE.

In order to save the next distracted traveler in PCI Address Land
some time, document this fact with a comment. Add a test case for
the behavior as well.
2016-10-17 10:04:54 +02:00
Michal Privoznik
e1844d85cb qemuBuildHostNetStr: Support VIR_DOMAIN_NET_TYPE_VHOSTUSER
https://bugzilla.redhat.com/show_bug.cgi?id=1366505

So far, this function lacked support for
VIR_DOMAIN_NET_TYPE_VHOSTUSER leaving callers to hack around the
problem by constructing the command line on their own. This is
not ideal as it blocks hot plug support.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-10-14 11:45:01 +08:00
Michal Privoznik
b093e85224 qemuBuildVhostuserCommandLine: Unify -netdev creation
Currently, what we do for vhost-user network is generate the
following part of command line:

-netdev type=vhost-user,id=hostnet0,chardev=charnet0

There's no need for 'type=' it is the default. Drop it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-10-14 11:45:01 +08:00
Michal Privoznik
4a74ccdb92 qemuBuildInterfaceCommandLine: Move vhostuser handling a bit further
The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-10-14 10:15:51 +08:00
Michal Privoznik
ec7f612a56 qemuBuildInterfaceCommandLine: Move hostdev handling a bit further
The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-10-14 10:15:51 +08:00
Pavel Hrdina
fb8f3b1c22 qemu_command: add support to use virtio as secondary video device
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1369633

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:48 +02:00
Pavel Hrdina
4c029e8cfa qemu_command: properly detect which model to use for video device
This improves commit 706b5b6277 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not.  This is not a case only for arm/aarch64.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:48 +02:00
Pavel Hrdina
34a4447bd4 qemu_capabilities: join capabilities for qxl and qxl-vga devices
This patch simplifies QEMU capabilities for QXL video device.  QEMU
exposes this device as *qxl-vga* and *qxl* and they are both the same
device with the same set of parameters, the only difference is that
*qxl-vga* includes VGA compatibility.

Based on QEMU code they are tied together so it's safe to check only for
presence of only one of them.

This patch also removes an invalid test case "video-qxl-sec-nodevice"
where there is only *qxl-vga* device and *qxl* device is not present.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:47 +02:00
Pavel Hrdina
e3bbdd9b06 tests: fix some QXL capability combinations that don't make sense
If one of QEMU_CAPS_DEVICE_QXL_VGA or QEMU_CAPS_DEVICE_QXL is set the
other one will always be set as well because both devices are tied
together in QEMU.

The change of args files is caused by the presence of capability
QEMU_CAPS_DEVICE_VIDEO_PRIMARY which means it's safe to use
"-device qxl-vga" instead of "-vga qxl", see commit (e3f2686b) and
by the fact that if QEMU_CAPS_VGA_QXL is set QEMU_CAPS_DEVICE_QXL_VGA
and QEMU_CAPS_DEVICE_QXL would be set too (since we support only qemu
with "-device" option).

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:47 +02:00
Daniel P. Berrange
5dee668632 qemu: fix command line building for iommu devices
The intel-iommu device has existed since QEMU 2.2.0, but
it was only possible to create it with -device since
QEMU 2.7.0, thanks to:

  commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
  Author: Marcel Apfelbaum <marcel@redhat.com>
  Date:   Mon Jun 27 18:38:34 2016 +0300

    hw/iommu: enable iommu with -device

    Use the standard '-device intel-iommu' to create the IOMMU device.
    The legacy '-machine,iommu=on' can still be used.

The libvirt capability check & command line formatting code
is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.

This fixes it to use iommu=on instead.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-07 16:52:35 +01:00
John Ferlan
a1417d5305 qemu: Convert from shorthand to longer throttling names
We're about to add 6 new options and it appears (from testing) one cannot
utilize both the shorthand (alias) and (much) longer names for the arguments.
So modify the command builder to use the longer name and of course alter the
test output .args to have the similarly innocuous long name.

Also utilize a macro to build that name makes it so much more visually
appealing and saves a few characters or potential cut-n-paste issues.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-10-05 18:53:55 -04:00
John Ferlan
c3584265ba tests: Add blkdeviotune-max xml2xmltest
It was missing... Also since I'm using the soft link from qemuxml2xmloutdata
to the qemuxml2argvdata file, modify the output file to have the necessary
<address> elements plus the mouse and keyboard.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-10-05 18:53:55 -04:00
Martin Kletzander
ff3112f3dc qemu: Only use memory-backend-file with NUMA if needed
If this reminds you of a commit message from around a year ago, it's
41c2aa729f and yes, we're dealing with
"the same thing" again.  Or f309db1f4d and
it's similar.

There is a logic in place that if there is no real need for
memory-backend-file, qemuBuildMemoryBackendStr() returns 0.  However
that wasn't the case with hugepage backing.  The reason for that was
that we abused the 'pagesize' variable for storing that information, but
we should rather have a separate one that specifies whether we really
need the new object for hugepage backing.  And that variable should be
set only if this particular NUMA cell needs special treatment WRT
hugepages.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-29 15:43:13 +02:00
Jiri Denemark
7ce711a30e qemu: Update guest CPU def in live XML
Storing the updated CPU definition in the live domain definition saves
us from having to update it over and over when we need it. Not to
mention that we will soon further update the CPU definition according to
QEMU once it's started.

A highly wanted side effect of this patch, libvirt will pass all CPU
features explicitly specified in domain XML to QEMU, even those that are
already included in the host model.

This patch should fix the following bugs:
    https://bugzilla.redhat.com/show_bug.cgi?id=1207095
    https://bugzilla.redhat.com/show_bug.cgi?id=1339680
    https://bugzilla.redhat.com/show_bug.cgi?id=1371039
    https://bugzilla.redhat.com/show_bug.cgi?id=1373849
    https://bugzilla.redhat.com/show_bug.cgi?id=1375524
    https://bugzilla.redhat.com/show_bug.cgi?id=1377913

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:09 +02:00
Jiri Denemark
0b7cf7f744 qemuxml2argvtest: Reorder CPU features
The x86 CPU driver translated each CPU definition from domain XML into
CPUID data and then back to CPU definition. This effectively sorted the
list of CPU features according to their CPUID values. Since this is
going to change, we need to reorder CPU features in a few test files to
make sure the generated QEMU command lines will not change.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Jiri Denemark
b89fa6d1b6 qemuxml2argvtest: Properly setup CPU models in qemuCaps
Adding x86 CPU models into a list of supported CPUs for non-x86
architectures is not a very good idea. Each architecture we test needs
to maintain its own list of supported CPU models.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Martin Kletzander
6b5622e4b5 qemu: Reorder shmem params nicely
Always format id first so that we don't need to do that twice in
different code paths.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-20 15:42:43 +02:00
Laszlo Ersek
706b5b6277 qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64)
Most of QEMU's PCI display device models, such as:

  libvirt video/model/@type  QEMU -device
  -------------------------  ------------
  cirrus                     cirrus-vga
  vga                        VGA
  qxl                        qxl-vga
  virtio                     virtio-vga

come with a linear framebuffer (sometimes called "VGA compatibility
framebuffer"). This linear framebuffer lives in one of the PCI device's
MMIO BARs, and allows guest code (primarily: firmware drivers, and
non-accelerated OS drivers) to display graphics with direct memory access.

Due to architectural reasons on aarch64/KVM hosts, this kind of
framebuffer doesn't / can't work in

  qemu-system-(arm|aarch64) -M virt

machines. Cache coherency issues guarantee a corrupted / unusable display.
The problem has been researched by several people, including kvm-arm
maintainers, and it's been decided that the best way (practically the only
way) to have boot time graphics for such guests is to consolidate on
QEMU's "virtio-gpu-pci" device.

>From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt
supports

  <devices>
    <video>
      <model type='virtio'/>
    </video>
  </devices>

but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga"
device model. (See the qemuBuildDeviceVideoStr() function and the
"qemuDeviceVideo" enum impl.)

According to the above, this is not right for the "virt" machine type; the
qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
virtio device without a compatibility framebuffer, is available, and works
fine.

(The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
for "virt" -- supports "virtio-gpu-pci", as of upstream commit
3ef3209d3028. See
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)

Override the default mapping of "virtio", from "virtio-vga" to
"virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.

Cc: Andrea Bolognani <abologna@redhat.com>
Cc: Drew Jones <drjones@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Martin Kletzander <mkletzan@redhat.com>
Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 14:13:07 +02:00