This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

For type='ethernet' interfaces only.

(This patch had been pushed earlier in
commit 0b4645a7, but was reverted in
commit 84d47a3c because it had been
accidentally pushed during the freeze for release 2.0.0)

For a luks device, allow the configuration of a specific cipher to be
used for encrypting the volume.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add parse and format of the luks/passphrase secret including tests for
volume XML parsing.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.

This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This test assumes the XML will be the same after formatting.
Add USB addresses to it to keep it working when we autoassign them.

I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.

https://bugzilla.redhat.com/show_bug.cgi?id=1323085Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Verify that SCSI controllers get created automatically when a SCSI disk
is hot-plugged to a domain that doesn't have a matching SCSI controller
defined already.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

This reverts commit 0b4645a7.

This feature was accidentally pushed in the feature freeze.

For type='ethernet' interfaces only.

The test has too many USB devices.

We support up to four levels of nested USB devices in the guest.

Add a test for a domain using all four and a negative test for a domain
using five.

Make them work again...  The xml2xml had been working, but the xml2argv
were not working. Making the xml2argv work required a few adjustments to
the xml to update to more recent times.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The default USB controller only has two ports.

The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.

However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.

Avoid it completely, like it's already happening for q35.

There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.

Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.

Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).

This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This option allows or disallows detection of zero-writes if it is set to
"on" or "off", respectively.  It can be also set to "unmap" in which
case it will try discarding that part of image based on the value of the
"discard" option.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

This new listen type is currently supported only by spice graphics.
It's introduced to make it easier and clearer specify to not listen
anywhere in order to start a guest with OpenGL support.

The old way to do this was set spice graphics autoport='no' and don't
specify any ports.  The new way is to use <listen type='none'/>.  In
order to be able to migrate to old libvirt the migratable XML will be
generated without the listen element and with autoport='no'.  Also the
old configuration will be automatically converted to the this listen
type.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

VNC graphics already supports sockets but only via 'socket' attribute.
This patch coverts that attribute into listen type 'socket'.

For backward compatibility we need to handle listen type 'socket' and 'socket'
attribute properly to support old XMLs and new XMLs.  If both are provided they
have to match, if only one of them is provided we need to be able to parse that
configuration too.

To not break migration back to old libvirt if the socket is provided by user we
need to generate migratable XML without the listen element and use only 'socket'
attribute.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Until now, the only hot thing in this test was the name.  That's because
we set the id to '-1' before every test.  With this change, we test the
hotplug on live domains as the name suggests and as it should be.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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.

<os>
  <acpi>
    <table type="slic">/path/to/acpi/table/file</table>
  </acpi>
</os>

will result in:

-acpitable sig=SLIC,file=/path/to/acpi/table/file

This option was introduced by QEMU commit 8a92ea2 in 2009.

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

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 test requests a read-only virtual FAT drive on the IDE bus.
Read-only IDE drives are unsupported, but libvirt only displays
the error if it has the QEMU_CAPS_DRIVE_READONLY capability.
Read-write FAT drives are also unsupported.

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

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

If they're available and we need to pass secrets to qemu, then use the
qemu domain secret object in order to pass the secrets for RBD volumes
instead of passing the base64 encoded secret on the command line.

The goal is to make AES secrets the default and have no user interaction
required in order to allow using the AES mechanism. If the mechanism
is not available, then fall back to the current plain mechanism using
a base64 encoded secret.

New APIs:

qemu_domain.c:
  qemuDomainGetSecretAESAlias:
    Generate/return the secret object alias for an AES Secret Info type.
    This will be called from qemuDomainSecretAESSetup.

  qemuDomainSecretAESSetup: (private)
    This API handles the details of the generation of the AES secret
    and saves the pieces that need to be passed to qemu in order for
    the secret to be decrypted. The encrypted secret based upon the
    domain master key, an initialization vector (16 byte random value),
    and the stored secret. Finally, the requirement from qemu is the IV
    and encrypted secret are to be base64 encoded.

qemu_command.c:
  qemuBuildSecretInfoProps: (private)
    Generate/return a JSON properties object for the AES secret to
    be used by both the command building and eventually the hotplug
    code in order to add the secret object. Code was designed so that
    in the future perhaps hotplug could use it if it made sense.

  qemuBuildObjectSecretCommandLine (private)
    Generate and add to the command line the -object secret for the
    secret. This will be required for the subsequent RBD reference
    to the object.

  qemuBuildDiskSecinfoCommandLine (private)
    Handle adding the AES secret object.

Adjustments:

qemu_domain.c:
  The qemuDomainSecretSetup was altered to call either the AES or Plain
  Setup functions based upon whether AES secrets are possible (we have
  the encryption API) or not, we have secrets, and of course if the
  protocol source is RBD.

qemu_command.c:
  Adjust the qemuBuildRBDSecinfoURI API's in order to generate the
  specific command options for an AES secret, such as:

    -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted,
            format=base64
    -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\
           mon_host=mon1.example.org\:6321,password-secret=$alias,...

  where the 'id=' value is the secret object alias generated by
  concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey'
  is the master key shared with qemu, and the -drive syntax will
  reference that alias as the 'password-secret'. For the -drive
  syntax, the 'id=myname' is kept to define the username, while the
  'key=$base64 encoded secret' is removed.

  While according to the syntax described for qemu commit '60390a21'
  or as seen in the email archive:

    https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html

  it is possible to pass a plaintext password via a file, the qemu
  commit 'ac1d8878' describes the more feature rich 'keyid=' option
  based upon the shared masterKey.

Add tests for checking/comparing output.

NB: For hotplug, since the hotplug code doesn't add command line
    arguments, passing the encoded secret directly to the monitor
    will suffice.

This is required for following patches where new listen types will be
introduced.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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>

There's no reason for keeping the features in a linked list. Especially
when we know upfront the total number of features we are loading.
Signed-off-by: NJiri Denemark <jdenemar@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.