Commit Graph

675 Commits

Author SHA1 Message Date
Laine Stump
147ebe6ddf conf: aggregate multiple pcie-root-ports onto a single slot
Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so
that they will be assigned to all the functions on a slot.

Some qemu test case outputs had to be adjusted due to the
pcie-root-ports now being put on multiple functions.
2017-01-11 04:45:57 -05:00
Laine Stump
8f4008713a qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed
If there are multiple devices assigned to the different functions of a
single PCI slot, they will not work properly if the device at function
0 doesn't have its "multi" attribute turned on, so it makes sense for
libvirt to turn it on during PCI address assignment. Setting multi
then assures that the new setting is stored in the config (so it will
be used next time the domain is started), preventing any potential
problems in the case that a future change in the configuration
eliminates the devices on all non-0 functions (multi will still be set
for function 0 even though it is the only function in use on the slot,
which has no useful purpose, but also doesn't cause any problems).

(NB: If we were to instead just decide on the setting for
multifunction at runtime, a later removal of the non-0 functions of a
slot would result in a silent change in the guest ABI for the
remaining device on function 0 (although it may seem like an
inconsequential guest ABI change, it *is* a guest ABI change to turn
off the multi bit).)
2017-01-11 04:42:08 -05:00
Andrea Bolognani
1d8454639f qemu: Use virtio-pci by default for mach-virt guests
virtio-pci is the way forward for aarch64 guests: it's faster
and less alien to people coming from other architectures.
Now that guest support is finally getting there (Fedora 24,
CentOS 7.3, Ubuntu 16.04 and Debian testing all support
virtio-pci out of the box), we'd like to start using it by
default instead of virtio-mmio.

Users and applications can already opt-in by explicitly using

  <address type='pci'/>

inside the relevant elements, but that's kind of cumbersome and
requires all users and management applications to adapt, which
we'd really like to avoid.

What we can do instead is use virtio-mmio only if the guest
already has at least one virtio-mmio device, and use virtio-pci
in all other situations.

That means existing virtio-mmio guests will keep using the old
addressing scheme, and new guests will automatically be created
using virtio-pci instead. Users can still override the default
in either direction.

Existing tests such as aarch64-aavmf-virtio-mmio and
aarch64-virtio-pci-default already cover all possible
scenarios, so no additions to the test suites are necessary.
2017-01-10 12:33:53 +01:00
Maxim Nestratov
245d9ba21e tests: Add "no-kvm-pit-device" testcase
Add a test case for when the QEMU_CAPS_NO_KVM_PIT capability is set.
This capability is mutually exclusive to QEMU_CAPS_KVM_PIT_TICK_POLICY
and results in the same output regardless of whether "discard" or
"delay" was specified in the guest XML for 'tickpolicy'.

Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
2017-01-06 18:27:06 -05:00
Maxim Nestratov
af78cb0486 qemu: Allow to specify pit timer tick policy=discard
Separate out the "policy=discard" into it's own specific
qemu command line.

We'll rename "kvm-pit-device" test case to be "kvm-pit-discard"
since it has the syntax we'd be using.

Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
2017-01-06 18:27:06 -05:00
Maxim Nestratov
ef5c8bb412 qemu: Fix pit timer tick policy=delay
By a mistake, for the VIR_DOMAIN_TIMER_TICKPOLICY_DELAY qemu
command line creation, 'discard' was used instead of 'delay'
in commit id '1569fa14'.

Test "kvm-pit-delay" is fixed accordingly to show the correct
option being generated.

Remove the (now) redundant kvm-pit-device tests. As it turns
out there is no need to specify both QEMU_CAPS_NO_KVM_PIT and
QEMU_CAPS_KVM_PIT_TICK_POLICY since they are mutually exclusive
and "kvm-pit-device" becomes just the same as "kvm-pit-delay".

Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
2017-01-06 18:27:06 -05:00
Collin L. Walling
d47db7b16d qemu: command: Support new cpu feature argument syntax
Qemu has abandoned the +/-feature syntax in favor of key=value. Some
architectures (s390) do not support +/-feature. So we update libvirt to handle
both formats.

If we detect a sufficiently new Qemu (indicated by support for qmp
query-cpu-model-expansion) we use key=value else we fall back to +/-feature.

Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 12:24:57 +01:00
Jason J. Herne
27e411fa83 tests: qemuxml2argv s390x cpu model
Test cases for qemu s390x cpu model argument generation.

Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 12:24:57 +01:00
Marc Hartmayer
86fd4e305e tests: Add tests for disk configuration validation
Add tests for controller based disks to check disk address compatibility
with disk bus types.

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
2016-12-20 11:34:30 +01:00
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
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
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
Jiri Denemark
a1adfb0f06 qemu: Add support for unavailable-features
QEMU 2.8.0 adds support for unavailable-features in
query-cpu-definitions reply. The unavailable-features array lists CPU
features which prevent a corresponding CPU model from being usable on
current host. It can only be used when all the unavailable features are
disabled. Empty array means the CPU model can be used without
modifications.

We can use unavailable-features for providing CPU model usability info
in domain capabilities XML:

    <domainCapabilities>
      ...
      <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'>
          <model fallback='allow'>Skylake-Client</model>
          ...
        </mode>
        <mode name='custom' supported='yes'>
          <model usable='yes'>qemu64</model>
          <model usable='yes'>qemu32</model>
          <model usable='no'>phenom</model>
          <model usable='yes'>pentium3</model>
          <model usable='yes'>pentium2</model>
          <model usable='yes'>pentium</model>
          <model usable='yes'>n270</model>
          <model usable='yes'>kvm64</model>
          <model usable='yes'>kvm32</model>
          <model usable='yes'>coreduo</model>
          <model usable='yes'>core2duo</model>
          <model usable='no'>athlon</model>
          <model usable='yes'>Westmere</model>
          <model usable='yes'>Skylake-Client</model>
          ...
        </mode>
      </cpu>
      ...
    </domainCapabilities>

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-28 09:11:22 +01:00
Jiri Denemark
7bf6f345e0 qemu: Probe CPU models for KVM and TCG
CPU models (and especially some additional details which we will start
probing for later) differ depending on the accelerator. Thus we need to
call query-cpu-definitions in both KVM and TCG mode to get all data we
want.

Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid
having to squash even more stuff into this single patch. They will all
be switched back later in separate commits.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Michal Privoznik
c2a5a4e7ea virstring: Unify string list function names
We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 13:54:05 +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
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
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
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
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
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
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
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
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
33af92a91c qemu_process: always check capabilities for video devices
Before this patch we've checked qemu capabilities for video devices
only while constructing qemu command line using "-device" option.

Since we support qemu only if "-device" option is present we can use
the same capabilities to check also video devices while using "-vga"
option to construct qemu command line.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:47 +02:00
Pavel Hrdina
db4491571d qemu_capabilities: rename QEMU_CAPS_VIRTIO_GPU_VIRGL
We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some
device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property
of that device.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:47 +02:00
Pavel Hrdina
05af6784b1 qemu_capabilities: mark QEMU_CAPS_VGA_QXL capability as deprecated
If QEMU in question supports QMP, this capability is set if
QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
libvirt needs to parse *help*, because there is no QMP support, it
checks for existence of "-vga qxl", but it also parses output of
"-device ?" and sets QEMU_CAPS_DEVICE_QXL too.

Now that libvirt supports only QEMU that has "-device" implemented it's
safe to drop this capability and stop using it.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-12 17:46:47 +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
Jiri Denemark
c2c43912e4 qemu: Fix crash in qemucapsprobe
The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with
caps == NULL, causing the following crash:

    Program received signal SIGSEGV, Segmentation fault.
    #0  0x00007ffff788775f in virQEMUCapsInitHostCPUModel
        (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at
        src/qemu/qemu_capabilities.c:2969
    #1  0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal
        (caps=caps@entry=0x0, binary=<optimized out>,
        libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0,
        runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295,
        qmpOnly=true) at src/qemu/qemu_capabilities.c:4039
    #2  0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at
        tests/qemucapsprobe.c:73

Caused by v2.2.0-182-g68c7011.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-27 19:24:12 +02:00
Michal Privoznik
c41b989112 virDomainDefParse{File,String}: Introduce @parseOpaque argument
We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-09-26 16:50:12 +02:00
Jiri Denemark
68c7011856 qemu: Store host-model CPU in qemu capabilities
Host capabilities provide libvirt's view of the host CPU, but for a
useful support for host-model CPUs we really need a hypervisor's view of
the CPU. And since the view can be differ with emulator, qemu
capabilities is the best place to store the host CPU model.

This patch just copies the CPU model from host capabilities, but this
will change in the future.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Jiri Denemark
d029f9a0db qemuxml2argvtest: Set correct architecture for KVM guests
Testing PPC64/AArch64 KVM domains on x86_64 host only works because we
have a lot of bugs in our code. Since this series is going to fix them,
we need to make sure the host architecture matches guest for KVM
domains.

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
Jiri Denemark
e9634933ea qemu: Separate guest CPU validation from command line creation
qemu_command.c should deal with translating our domain definition into a
QEMU command line and nothing else.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Jiri Denemark
6bb5f0b218 qemuxml2argvtest: Properly initialize qemuCaps->arch
qemuCaps->arch should match the guest architecture from domain XML.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Jiri Denemark
4df4b8dea3 qemuxml2argvtest: Update qemuCaps after parsing domain XML
Some parts of qemuCaps depend on guest architecture, machine type, and
possibly other things that we know only once the domain XML has been
parsed. Let's move all these updates into a dedicated function.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Jiri Denemark
30de7164ef qemuxml2argvtest: Reorder functions
testCompareXMLToArgv will soon need to call a few function which are
defined further in the code. Let's move them up a bit.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00