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

USB controllers can share the same 'index' which indicates, that there
is some sort of master-companion relationship.  Reorder the controllers
in XML in to place the master controller before its companions.  This is
required by QEMU to not fail with error message:

error: internal error: process exited while connecting to monitor:
2015-10-26T16:25:17.630265Z qemu-system-x86_64:
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6:
USB bus 'usb.0' not found

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1166452Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

Introduced by 8fedbbdb, if we parse an unordered NUMA cell, will
get a segfault. This is because of a check for overlapping @cpus
sets we have there. However, since the array to hold guest NUMA
cells is allocated upfront and therefore it contains all zeros,
an out of order cell will break our assumption that cell IDs have
increasing character. At this point we try to access yet NULL
bitmap and therefore segfault.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

There are some configuration options to some types of pci controllers
that are currently automatically derived from other parts of the
controller's configuration. For example, in qemu a pci-bridge
controller has an option that is called "chassis_nr"; up until now
libvirt has always set chassis_nr to the index of the pci-bridge. So
this:

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

will always result in:

  -device pci-bridge,chassis_nr=2,...

on the qemu commandline. In the future we may decide there is a better
way to derive that option, but even in that case we will need for
existing domains to retain the same chassis_nr they were using in the
past - that is something that is visible to the guest so it is part of
the guest ABI and changing it would lead to problems for migrating
guests (or just guests with very picky OSes).

The <target> subelement has been added as a place to put the new
"chassisNr" attribute that will be filled in by libvirt when it
auto-generates the chassisNr; it will be saved in the config, then
reused any time the domain is started:

  <controller type='pci' model='pci-bridge' index='2'>
    <model type='pci-bridge'/>
    <target chassisNr='2'/>
  </controller>

The one oddity of all this is that if the controller configuration
is changed (for example to change the index or the pci address
where the controller is plugged in), the items in <target> will
*not* be re-generated, which might lead to conflict. I can't
really see any way around this, but fortunately if there is a
material conflict qemu will let us know and we will pass that on
to the user.

This new subelement is used in PCI controllers: the toplevel
*attribute* "model" of a controller denotes what kind of PCI
controller is being described, e.g. a "dmi-to-pci-bridge",
"pci-bridge", or "pci-root". But in the future there will be different
implementations of some of those types of PCI controllers, which
behave similarly from libvirt's point of view (and so should have the
same model), but use a different device in qemu (and present
themselves as a different piece of hardware in the guest). In an ideal
world we (i.e. "I") would have thought of that back when the pci
controllers were added, and used some sort of type/class/model
notation (where class was used in the way we are now using model, and
model was used for the actual manufacturer's model number of a
particular family of PCI controller), but that opportunity is long
past, so as an alternative, this patch allows selecting a particular
implementation of a pci controller with the "name" attribute of the
<model> subelement, e.g.:

  <controller type='pci' model='dmi-to-pci-bridge' index='1'>
    <model name='i82801b11-bridge'/>
  </controller>

In this case, "dmi-to-pci-bridge" is the kind of controller (one that
has a single PCIe port upstream, and 32 standard PCI ports downstream,
which are not hotpluggable), and the qemu device to be used to
implement this kind of controller is named "i82801b11-bridge".

Implementing the above now will allow us in the future to add a new
kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
device, but instead uses something else (which doesn't yet exist, but
qemu people have been discussing it), all without breaking existing
configs.

(note that for the existing "pci-bridge" type of PCI controller, both
the model attribute and <model> name are 'pci-bridge'. This is just a
coincidence, since it turns out that in this case the device name in
qemu really is a generic 'pci-bridge' rather than being the name of
some real-world chip)

Multi != One.  And indeed, libvirt behaves the same way for queues='1'
as without such setting.  Let's make it clear in the XML.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We have been formatting the first serial device also
as a console device, but only if there were no other consoles.

If there is a <serial> device present in the XML, but no serial
<console>, or if there isn't any <console> at all but the domain
definition hasn't gone through a parse->format->parse round-trip,
the <console> device would not be formatted.

Change the code to always add the stub device for the first
serial device.

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

The guest firmware provides the same functionality as the pvpanic
device, and the relevant element should always be present in the
domain XML to reflect this fact, so add it after parsing the
definition if it wasn't there already.

We have previously effectively ignored all <controller type='ide'>
elements in a domain definition.

On the i440fx-based machinetypes there is an IDE controller that is
included in the chipset and can't be removed (which is the ide
controller with index='0'>), so it makes sense to ignore that one
controller. However, if an i440fx domain definition has a 2nd
controller, nothing catches this error (unless you also have a disk
attached to it, in which case qemu will complain that you're trying to
use the ide controller named "ide1", which doesn't exist), and if any
other type of domain has even a single controller defined, it will be
incorrectly ignored.

Ignoring a bogus controller definition isn't such a big problem, as
long as an error is logged when any disk is attached to that
non-existent controller. But in the case of q35-based machinetypes,
the hardcoded id ("alias" in libvirt terms) of its builtin SATA
controller is "ide", which happens to be the same id as the builtin
IDE controller on i440fx machinetypes. So libvirt creates a
commandline believing that it is connecting the disk to the builtin
(but actually nonexistent) IDE controller, qemu thinks that libvirt
wanted that disk connected to the builtin SATA controller, and
everybody is happy.

Until you try to connect a 2nd disk to the IDE controller. Then qemu
will complain that you're trying to set unit=1 on a controller that
requires unit=0 (SATA controllers are organized differently than IDE
controllers).

After this patch, if a domain has an IDE controller defined for a
machinetype that has no IDE controllers, libvirt will log an error
about the controller itself as it is building the qemu commandline
(rather than a (possible) error from qemu about disks attached to that
controller). This is done by adding IDE to the list of controller
types that are handled in the loop that creates controller command
strings in qemuBuildCommandline() (previously it would *always* skip
IDE controllers). Then qemuBuildControllerDevStr() is modified to log
an appropriate error in the case of IDE controllers.

In the future, if we add support for extra IDE controllers (piix3-ide
and/or piix4-ide) we can just add it into the IDE case in
qemuBuildControllerDevStr(). For now, nobody seems anxious to add
extra support for an aging and very slow controller, when there are so
many better options available.

Resolves:

https://bugzilla.redhat.com/show_bug.cgi?id=1176071 (Fedora)

My commit 747761a7 (v1.2.15 only) dropped this bit of logic when filling
in a default arch in the XML:

-    /* First try to find one matching host arch */
-    for (i = 0; i < caps->nguests; i++) {
-        if (caps->guests[i]->ostype == ostype) {
-            for (j = 0; j < caps->guests[i]->arch.ndomains; j++) {
-                if (caps->guests[i]->arch.domains[j]->type == domain &&
-                    caps->guests[i]->arch.id == caps->host.arch)
-                    return caps->guests[i]->arch.id;
-            }
-        }
-    }

That attempt to match host.arch is important, otherwise we end up
defaulting to i686 on x86_64 host for KVM, which is not intended.
Duplicate it in the centralized CapsLookup function.

Additionally add some testcases that would have caught this.

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

My commit 7b9de914 added some aarch64 CPU test cases. I wanted to test
two different code paths but inadvertently added two of the same test
cases.

The second code path (using <cpu><model>host</model</cpu>) isn't easily
exercised via the qemu tests anyways, I'll need to look elsewhere.

Regardless, remove the redundant tests for now

Remove the iothreadspin array from cputune and replace with a cpumask
to be stored in the iothreadids list.

Adjust the test output because our printing goes in order of the iothreadids
list now.

- Make sure aarch64 host-passthrough works correctly
- Make sure libvirt doesn't choke on cpu model=host, which is what
  virt-install/virt-manager were incorrectly specifying up until recently.

Request that the number be parsed as decimal, to allow 08
and 09.

Format it with the leading zero, 1.01 and 1.10 are two
different versions.

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

We don't format the default '-1' fields back.

The tag is already marked as optional in the schema, so no changes
are needed there.

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