Requires adding the plumbing for <device><graphics>
Wire it up for qemu too

qemuDomainCheckDiskPresence has short-circuit code to skip the
determination of the disk backing chain for storage formats that can't
have backing volumes. The code treats VIR_STORAGE_FILE_NONE as not
having backing chain and skips the call to qemuDomainDetermineDiskChain.

This is wrong as qemuDomainDetermineDiskChain is responsible for storage
format detection and has logic to determine the default type if format
detection is disabled.

This allows to storage passed via <disk type="volume"> to circumvent the
enforcement to have correct storage format or that we shall default to
format='raw', since we don't set the default type via the post parse
callback for "volume" backed disks as the translation code could come up
with a better guess.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1328003

Extract the relevant parts of the existing checker and reuse them for
blockcopy since copying to a non-block device creates an invalid
configuration.

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

In qemuCheckDiskConfig would now use virDomainDiskSourceIsBlockType just
as a glorified version of virStorageSourceIsBlockLocal that reports
error messages. Replace it with the latter including the message for
clarity.

Commit c820fbff added support for iSCSI
disk as backing for <disk device='lun'>. We would not use it for a disk
type="volume" with direct access mode which basically maps to direct
iSCSI usage. Fix it by adding the storage source type accessor that
resolves the volume type.

For disks sources described by a libvirt volume we don't need to do a
complicated check since virStorageTranslateDiskSourcePool already
correctly determines the actual disk type.

Replace the checks using a new accessor that does not open-code the
whole logic.

In 7884d089 I've started to refactor qemu_monitor_json.c.
Thing is, it's current structure is nothing like the rest of our
code. The @ret variable is rewritten all the time, if()-s are
nested instead of using goto and so on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

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

Move adding the config listen type=address if there is none in
qemuProcessPrepareDomain and move check for multiple listens to
qemuProcessStartValidate.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

We will need to use the formatter directly for testing QEMU capabilities
code.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Add the data structure and infrastructure to support an initialization
vector (IV) secrets. The IV secret generation will need to have access
to the domain private master key, so let's make sure the prepare disk
and hostdev functions can accept that now.

Anywhere that needs to make a decision over which secret type to use
in order to fill in or use the IV secret has a switch added.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create helper API's in order to build the network URI as shortly we will
be adding a new SecretInfo type
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than need to call qemuDomainSecretDestroy after any call to
qemuProcessLaunch, let's do the destroy in qemuProcessLaunch since
that's where command line is eventually generated and processed. Once
it's generated, we can clear out the secrets.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '40d8e2ba' added the function to qemuProcessStart because
in order to set up some secrets in the future we will need the master
key. However, since the previous patch split the master key creation
into two parts (create just the key and create the file), we can now
call qemuDomainSecretPrepare from qemuProcessPrepareDomain since the
file is not necessary.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

A recent review of related changes noted that we should split the creation
(or generation) of the master key into the qemuProcessPrepareDomain and leave
the writing of the master key for qemuProcessPrepareHost.

Made the adjustment and modified some comments to functions that have
changed calling parameters, but didn't change the intro doc.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

From a review after push, add the "_TYPE" into the name.

Also use qemuDomainSecretInfoType in the struct rather than int
with the comment field containing the struct name
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

virQEMUCapsNewForBinary unconditionally loads data from cache and probes
using both QMP and -help parsing, which is suboptimal when we want to
use it in tests.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Now that we have all the pieces in place, we can add the 'iothread=#' to
the command line for the (two) controllers that support it (virtio-scsi-pci
and virtio-scsi-ccw). Add the tests as well...

Rather than an if statement, use a switch.

The switch will also catch the illegal usage of 'iothread' with some other
kind of unsupported bus configuration.

An iothread for virtio-scsi is a property of the controller. Add a lookup
of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse
the output.  For both, support for the iothread was added in qemu 2.4
while support for virtio-scsi in general was added in qemu 1.4.

Modify the various mock capabilities replies (by hand) to reflect the
when virtio-scsi was supported and then specifically when the iothread
property was added. For versions prior to 1.4, use the no device error
return for virtio-scsi. For versions 1.4 to before 2.4, add some data
for virtio-scsi-pci even though it isn't complete we're not looking for
anything specific there anyway. For 2.4 to 2.6, add a more complete reply.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In majority of our functions we have this variable @ret that is
overwritten a lot. In other areas of the code we use 'goto
cleanup;' just so that this wouldn't happen. But here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This adds a ports= attribute to usb controller XML, like

  <controller type='usb' model='nec-xhci' ports='8'/>

This maps to:

  qemu -device nec-usb-xhci,p2=8,p3=8

Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.

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

Reports whether we support -device nec-usb-xhci,p3=XXX value,
which has been available since qemu 1.3.0

Rather than reimplement it. This will be needed in upcoming patches

In these functions I'm fixing here, we do call
qemuMonitorJSONCheckError() followed by another check if qemu
reply contains 'return' object. If it wouldn't, the former
CheckError() function would error out and the flow would not even
get to the latter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Usually, the flow in this area of the code is as follows:

qemuMonitorJSONMakeCommand()
qemuMonitorJSONCommand()
qemuMonitorJSONCheckError()
parseReply()

But in this function, for some reasons, the last two steps were
swapped. This makes no sense.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In qemuDomainDefAddDefaultDevices we check for a non-NULL
def->os.machine for x86 archs, but not the others.

Moreover, the only caller - qemuDomainDefPostParse
already checks for it and even then it can happen only
if /etc/libvirt contains an XML without a machine type.

Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.

It was not indented correctly.

We do not need to propagate the exact return values
and the only possible ones are 0 and -1 anyway.

Remove the temporary variable and use the usual pattern:

if (f() < 0)
    return -1;

This function does not fail and it does not need to return anything.

For all the other machine types, we use a positive condition.

Be more positive and use it for i440fx too.

Do not duplicate the string comparisons by writing them twice.

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

Thing is, for some reasons you can have your domain's RTC to be
in something different than UTC. More weirdly, it's not only time
zone what you can shift it of, but an arbitrary value. So, if
domain is configured that way, libvirt will correctly put it onto
qemu cmd line and moreover track it as this offset changes during
domain's life time (e.g. because guest OS decides the best thing
to do is set new time to RTC). Anyway, they way in which this
tracking is implemented is events. But we've got a problem if
change in guest's RTC occurs and the daemon is not running. The
event is lost and we end up reporting invalid value in domain
XML. Therefore, when the daemon is starting up again and it is
reconnecting to all running domains, re-fetch their RTC so the
correct offset value can be computed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>