Historically, we added heads=1 to videos, but for example for qxl, we
did not reflect that on the command line.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283207Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Hand-entering indexes for 20 PCI controllers is not as tedious as
manually determining and entering their PCI addresses, but it's still
annoying, and the algorithm for determining the proper index is
incredibly simple (in all cases except one) - just pick the lowest
unused index.

The one exception is USB2 controllers because multiple controllers in
the same group have the same index. For these we look to see if 1) the
most recently added USB controller is also a USB2 controller, and 2)
the group *that* controller belongs to doesn't yet have a controller
of the exact model we're just now adding - if both are true, the new
controller gets the same index, but in all other cases we just assign
the lowest unused index.

With this patch in place and combined with the automatic PCI address
assignment, we can define a PCIe switch with several ports like this:

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

These will each get a unique index, and PCI addresses that connect
them together appropriately with no pesky numbers required.

Add a new element to <domain> XML:
<os>
  <acpi>
    <table type="slic">/path/to/acpi/table/file</table>
  </acpi>
</os>

To supply a path to a SLIC (Software Licensing) ACPI
table blob.

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

Read-only IDE disks are not supported, but the error
is raised only when QEMU_CAPS_DRIVE_READONLY is set.

This is an interesting test case since PCI isn't the default for
aarch64.

Rather than only assigning a PCI address when no address is given at
all, also do it when the config says that the address type is 'pci',
but it gives no address (virDeviceInfoPCIAddressWanted()).

There are also several places after parsing but prior to address
assignment where code previously expected that any info with address
type='pci' would have a *valid* PCI address, which isn't always the
case - now we check not only for type='pci', but also for a valid
address (virDeviceInfoPCIAddressPresent()).

The test case added in this patch was directly copied from Cole's patch titled:

    qemu: Wire up address type=pci auto_allocate

Commit 55320c23 introduced a new test for VNC to test if
vnc_auto_unix_socket is set in qemu.conf, but forget to enable it in
qemuxml2argvtest.c.

This patch also moves the code in qemuxml2xmltest.c next to other VNC
tests and refactor the test so we also check the case for parsing active
XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We have stopped supporting Xenner some time ago.

The only case where the hardware capabilities influence the result
is when no <gic/> element was provided.

The test programs now ensure both that the correct GIC version is
picked in that case, and that hardware capabilities are not taken
into account when the user has already picked a GIC version.

We support omitting listen attribute of graphics element so we should
also support omitting address attribute of listen element.  This patch
also updates libvirt to always add a listen element into domain XML
except for VNC graphics if socket attribute is specified.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add the ability to add an 'iothread' to the controller which will be how
virtio-scsi-pci and virtio-scsi-ccw iothreads have been implemented in qemu.

Describe the new functionality and add tests to parse/validate that the
new attribute can be added.

Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

This patch adds by default a panic device with model s390 to S390 guests.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Similarly to what commit 71408079 did with some internal paths,
clear vnc socket paths that were generated by us.  Having such path in
the definition can cause trouble when restoring the domain.  The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.

To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated.  And mark it as autogenerated
if it already exists and we're parsing live XML.

Best viewed with '-C'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45

However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:

http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html

Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely

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

The hex range already tried to allow for it, but it wasn't using
the correct XML hex syntax. Fix it, and test it

While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).

Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.

So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.

Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).

Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).

This is backed by the qemu device "pxb".

The pxb device always includes a pci-bridge that is at the bus number
of the pxb + 1.

busNr and <node> from the <target> subelement are used to set the
bus_nr and numa_node options for pxb.

During post-parse we validate that the domain's machinetype is
440fx-based (since the pxb device only works on 440fx-based machines),
and <node> also gets a sanity check to assure that the NUMA node
specified for the pxb (if any - it's optional) actually exists on the
guest.

This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.

The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).

Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.

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.

Commit dc98a5bc refactored the code a lot and forget about checking if
listen attribute is specified.  This ensures that listen attribute and
first listen element are compared only if both exist.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This patch adds support for "vpindex", "runtime", "synic",
"stimer", and "vendor_id" features available in qemu 2.5+.

- When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX
to get virtual processor ID.

- Hyper-V "runtime" enlightement feature allows to use MSR
HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes
running guest code, as well as the time the hypervisor spends running
code on behalf of that guest.

- Hyper-V "synic" stands for Synthetic Interrupt Controller, which is
lapic extension controlled via MSRs.

- Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support.
Guest can setup and use fired by host events (SynIC interrupt and
appropriate timer expiration message) as guest clock events

- Hyper-V "reset" allows guest to reset VM.

- Hyper-V "vendor_id" exposes hypervisor vendor id to guest.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

We always place primary video device at first place, to make it easier
to create a qemu command or format an xml, but we should also set the
primary boolean for primary video device to 'true'.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add Spice graphics gl attribute. qemu 2.6 should have -spice gl=on argument to
enable opengl rendering context (patches on the ML). This is necessary to
actually enable virgl rendering.

Add a qemuxml2argv test for virtio-gpu + spice with virgl.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This does nothing more than adding the new device and capability.
The device is present since QEMU 2.6.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Test all kinds of scenarios, including guests asking for GIC but
failing to specify a version, guests specifying an invalid version
and guests trying to use GIC with non-virt or even non-ARM machines.

Unify the naming to prepare for new test cases that will be added
later on.

Convert a couple of output XML files for the qemuxml2xml test to
symlinks while at it, since they were identical to the corresponding
input XML files anyways.

Moreover, since we're only interested in testing GIC support here,
simplify XML files by getting rid of the unrelevant bits.

GIC is always available to ARM virt machines, and the domain XML should
reflect this fact.

Clarify the point of some of the test cases by renaming them. Add more
xml2xml tests.

We use the PreFormat callback for this. Many test cases need to be extended
to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors.

One test case (pcie-root-port-too-many) is dropped, since it was meant
only for checking an error condition in qemuxml2argv, and one we add in
AssignAddresses it errors here too.

Long term I think AssignAddresses should be handled in qemu's PostParse
callback, but that's not entirely straightforward. Handling it here
means we can get the test suite churn over with.

When we unconditionally enable QEMU_CAPS_DEVICE, these tests need
some massaging, so do it ahead of time to not mix it in with the
big test refresh.

- minimal-s390 is not a real world working config, so drop it
- disk-usb was testing for an old code path that will be removed.
  instead use it to test lack of USB disk support, and rename it
  to disk-usb-nosupport. Switch xml2xml to use disk-usb-device for
  input.
- cputune-numatune was needlessly using q35, switch it to an older
  machine type

Most qemuxml2xml tests expect that the input XML is unchanged after
parsing. This is unlike 99% of new qemu configs in the wild, which after
initial parsing end up with stable PCI device addresses. The xml2xml bit
doesn't currently hit that code path though, so most XML testing indeed
does not change.

Future patches will add that PCI address bits, which means most test cases
will have different output. So let's do away with the hardcoded same vs
different test split, and always track a separate output file. Tests can
still have same input and output, it just necessitates 2 separate XML files.

Similarly to previous commit change the way how iothread scheduler info
is stored and clean up a lot of unnecessary code.

The current code was a little bit odd.  At first we've removed all
possible implicit input devices from domain definition to add them later
back if there was any graphics device defined while parsing XML
description.  That's not all, while formating domain definition to XML
description we at first ignore any input devices with bus different to
USB and VIRTIO and few lines later we add implicit input devices to XML.

This seems to me as a lot of code for nothing.  This patch may look
to be more complicated than original approach, but this is a preferred
way to modify/add driver specific stuff only in those drivers and not
deal with them in common parsing/formating functions.

The update is to add those implicit input devices into config XML to
follow the real HW configuration visible by guest OS.

There was also inconsistence between our behavior and QEMU's in the way,
that in QEMU there is no way how to disable those implicit input devices
for x86 architecture and they are available always, even without graphics
device.  This applies also to XEN hypervisor.  VZ driver already does its
part by putting correct implicit devices into live XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

A future patch will refactor the storage of the pinning information in a
way where the ordering will be lost. Order them numerically to avoid
changing the tests later.

The real Q35 machine puts the first USB controller set (EHCI+(UHCIx4))
on bus 0 slot 0x1D, and the 2nd USB controller set on bus 0 slot 0x1A,
so let's attempt to make the virtual machine match that for
controllers with auto-assigned addresses when possible.

Three test cases were added to assure that the proper addresses are
assigned - one with a single set of unaddressed USB controllers, one
with 3 (to grab both preferred slots plus one more), and one with the
order of the controller definitions reordered, to assure that the
auto-assignment isn't mixed up by order.

Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash