qemu 2.7.0 introduces multiqueue virtio-blk(commit 2f27059).
This patch introduces a new attribute "queues". An example of
the XML:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' queues='4'/>

The corresponding QEMU command line:

-device virtio-blk-pci,scsi=off,num-queues=4,id=virtio-disk0
Signed-off-by: NLin Ma <lma@suse.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Add an optional virTristateBool haveTLS to virStorageSource to
manage whether a storage source will be using TLS.

Sample XML for a VxHS disk:

<disk type='network' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251' tls='yes'>
    <host name='192.168.0.1' port='9999'/>
  </source>
  <target dev='vda' bus='virtio'/>
</disk>

Additionally add a tlsFromConfig boolean to control whether the TLS
setting was due to domain configuration or qemu.conf global setting
in order to decide whether to Format the haveTLS setting for either
a live or saved domain configuration file.

Update the qemuxml2xmltest in order to add a test to show the proper
parsing.

Also update the docs to describe the tls attribute.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Alter the schema to allow a VxHS block device. Sample XML is:

  <disk type='network' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'>
      <host name='192.168.0.1' port='9999'/>
    </source>
    <target dev='vda' bus='virtio'/>
    <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </disk>

Update the html docs to describe the capability for VxHS.

Alter the qemuxml2xmltest to validate the formatting.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

Currently, all that users can specify for an interface type of
'user' is the common attributes: PCI address, NIC model (and
that's basically it). However, some need to configure other
address range than the default one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: laine@laine.org

Using intremap without <ioapic driver='qemu'/> does not work.
Merge the tests to avoid a duplicit test once we start validating it.

arm/aarch64 -M virt on KVM doesn't and will never work with standard
VGA card emulation. The recommended method is to use type=virtio, so
let's make it the default for video devices without an explicit type
set by the user.

https://bugzilla.redhat.com/show_bug.cgi?id=1404112Signed-off-by: NCole Robinson <crobinso@redhat.com>

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

This code is so complicated because we allow enabling the same
bits at many places. Just like in this case: huge pages can be
enabled by global <hugepages/> element under <memoryBacking> or
on per <memory/> basis. To complicate things a bit more, users
are allowed to omit the page size which case the default page
size is used. And this is what is causing this bug. If no page
size is specified, @pagesize is keeping value of zero throughout
whole function. Therefore we need yet another boolean to hold
[use, don't use] information as we can't sue @pagesize for that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

My commit 0c1d8632 broke formatting of passthrough smartcard devices:
<smartcard mode='passthrough' type='spicevmc'/>

resulted in invalid XML:
    <smartcard mode='passthrough'>
       type='spicevmc'>
      <address type='ccid' controller='0' slot='0'/>
    </smartcard>

Split out chardev source formatting function into two -
one formatting the attributes and other formatting the subelements.
Reported-by: NCole Robinson <crobinso@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Just like I've added support for setting rx_queue_size (in
c56cdf25 and friends), qemu just gained support for setting tx
ring size.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch addresses the same aspects on PPC the bug 1103314 addressed
on x86.

PCI expander bus creates multiple primary PCI busses, where each of these
busses can be assigned a specific NUMA affinity, which, on x86 is
advertised through ACPI on a per-bus basis.

For SPAPR, a PHB's NUMA affinities are assigned on a per-PHB basis, and
there is no mechanism for advertising NUMA affinities to a guest on a
per-bus basis. So, even if qemu-ppc manages to get some sort of multi-bus
topology working using PXB, there is no way to expose the affinities
of these busses to the guest. It can only be exposed on a per-PHB/per-domain
basis.

So patch enables NUMA node tag in pci-root controller on PPC.

The way to set the NUMA node is through the numa_node option of
spapr-pci-host-bridge device. However for the implicit PHB, the only way
to set the numa_node is from the -global option. The -global option applies
to all the PHBs unless explicitly specified with the option on the
respective PHB of CLI. The default PHB has the emulated devices only, so
the patch prevents setting the NUMA node for the default PHB.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Decouple them by storing them in the XML separately rather than
regenerating them. This will simplify upcoming fixes.

When looking for slots suitable for a PCI device, libvirt
might need to add an extra PCI controller: for pSeries guests,
we want that extra controller to be a PHB (pci-root) rather
than a PCI bridge.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

PCI bus has to be numbered sequentially, and no index can be
missing, so libvirt will fill in the blanks automatically for
the user.

Up until now, it has done so using either pci-bridge, for machine
types based on legacy PCI, or pcie-root-port, for machine types
based on PCI Express. Neither choice is good for pSeries guests,
where PHBs (pci-root) should be used instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

These tests demonstrate that, while it's now possible for the
user to create PHB explicitly and manually assign devices to
them, libvirt still defaults to extending the guest PCI
topology using PCI bridges and making suboptimal device
placement choices.

The next few commits will improve on these behaviors and the
tests outputs will automatically be updated to reflect this.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Later on we're going to need access to information about IOMMU
groups for host devices. Implement the support in virpcimock,
and start using that mock library in a few QEMU test cases.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Every qemu version we support has QEMU_CAPS_CHARDEV, so stop
explicitly tracking it and blacklist it like we've done for many
other feature flags.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

These tests are exercising old style -serial command lines. That
code will soon be removed, so drop these tests.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

AFAIK there aren't any qemu arch/machine types with platform parallel
devices that would require old style -parallel config, so we shouldn't
ever need this nowadays.

Remove a now redundant test
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This demonstrates that the previous qemu caps changes will use
-chardev for pci-serial on aarch64 machvirt
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Update the per device boot schema to add an optional loadparm parameter.

eg: <boot order='1' loadparm='2'/>

Extend the virDomainDeviceInfo to support loadparm option.
Modify the appropriate functions to parse loadparm from boot device xml.
Add the xml2xml test to validate the field.
Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

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

Consider the following XML:

  <memoryBacking>
    <hugepages>
      <page size='2048' unit='KiB' nodeset='1'/>
    </hugepages>
    <source type='file'/>
    <access mode='shared'/>
  </memoryBacking>

  <numa>
    <cell id='0' cpus='0-3' memory='512000' unit='KiB'/>
    <cell id='1' cpus='4-7' memory='512000' unit='KiB'/>
  </numa>

The following cmd line is generated:

  -object
  memory-backend-file,id=ram-node0,mem-path=/var/lib/libvirt/qemu/ram,
  share=yes,size=524288000 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0
  -object
  memory-backend-file,id=ram-node1,mem-path=/var/lib/libvirt/qemu/ram,
  share=yes,size=524288000 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1

This is obviously wrong as for node 1 hugepages should have been
used. The hugepages configuration is more specific than <source
type='file'/>.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Historically, we've always supported memAccess for domains backed
by hugepages. However, somewhere along the way we've regressed
and stopped allowing such configuration. Fix it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have couple of hugepage enabled domains for qemuxml2argvtest.
Unfortunately, often when adding a test case there I forget to
add it to xml2xml test too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a test case with all the virtio devices we know to demonstrate
the addition of new options.

https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Add a new iotlb attribute to the iommu device
to control the device IOTLB support for intel-iommu.

https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

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

Currently, we are querying for vhostuser interface name in post
parse callback. At that time interface might not yet exist.
However, it has to exist when starting domain. Therefore it makes
more sense to query its name at that point. This partially
reverts 57b5e27d.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add an attribute to control extended interrupt mode.

https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Currently we consider all UNIX paths with specific prefix as generated
by libvirt, but that's a wrong assumption.  Let's make the detection
better by actually checking whether the whole path matches one of the
paths that we generate or generated in the past.

The UNIX path isn't stored in config XML since libvirt-1.3.1.

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

Add a new attribute to control the caching mode.

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

Add a new <ioapic> element with a driver attribute.

Possible values are qemu and kvm. With 'qemu', the I/O
APIC can be put in the userspace even for KVM domains.

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

We are currently parsing only rx/frames/max because that's the only
value that makes sense for us.  The tun device just added support for
this one and the others are only supported by hardware devices which
we don't need to worry about as the only way we'd pass those to the
domain is using <hostdev/> or <interface type='hostdev'/>.  And in
those cases the guest can modify the settings itself.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This removes the hacky extern global variable and modifies the
test code to properly create QEMU capabilities cache for QEMU
binaries used in our tests.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit 5572cd7f deprecated QEMU_CAPS_DEVICE capability but forgot
to remove this call as well.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We use the "vir" prefix pretty consistently in our
APIs, both external and internal, which made these
macros stood out.

For now, these only cover the unmanaged, i.e. user pre-created devices.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We want pcie-root-ports to be used when available in QEMU,
but at the same time we need to ensure that hosts running
older QEMU releases keep working and that the user can
override the default at any time.

Add a comment for the original pcie-root-port test cases
to make it clear how these new test cases are different.