The base vfio has not much functionality but to provide a custom
container by opening this path.
See https://www.kernel.org/doc/Documentation/vfio.txt for more.

Systems with static hostdevs will get /dev/vfio/vfio by virt-aa-hotplug
right from the beginning. But if the guest initially had no hostdev at
all it will run into the following deny before the security module
labelling callbacks will make the actual vfio device (like /dev/vfio/93)
known.

Example of such a deny:
[ 2652.756712] audit: type=1400 audit(1491303691.719:25):
  apparmor="DENIED" operation="open"
  profile="libvirt-17a61b87-5132-497c-b928-421ac2ee0c8a"
  name="/dev/vfio/vfio" pid=8486 comm="qemu-system-x86"
  requested_mask="wr" denied_mask="wr" fsuid=64055 ouid=0

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1678322
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1775777Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Acked-by: NJamie Strandboge <jamie@canonical.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The typedefs were present twice in the header file which causes failures
with some compilers, eg FreeBSD 10 CLang:

../../src/conf/domain_conf.h:2330:33: error: redefinition of typedef 'virDomainSevDef' is a C11 feature
+[-Werror,-Wtypedef-redefinition]
typedef struct _virDomainSevDef virDomainSevDef;
                                ^
../../src/conf/domain_conf.h:145:33: note: previous definition is here
typedef struct _virDomainSevDef virDomainSevDef;
                                ^
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

As reported on https://bugs.debian.org/892431, without this rule, when launching
a QEMU KVM instance, an error occurs immediately upon launching the QEMU
process such as:

  Could not open backing file: Could not open
  '/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e':
  Permission denied

The other instance disk images are already covered by the existing rule:

  /**/disk{,.*} r
Signed-off-by: Nintrigeri <intrigeri@boum.org>

Use qemuMonitorTestNewFromFileFull which allows to test commands used
along with providing replies. This has two advantages:

1) It's easier to see which command was used when looking at the files
2) We check that the used commands are actually in the correct order
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Change the output of qemucapsprobe to record the commands used for
querying. This allows to easily identify which reply belongs to which
command and also will allow to test whether we use stable queries.

This change includes changing dropping of the QMP greeting from the file
and reformatting of the query and output to stdout.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Rather than skipping output on failure fail loudly.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The prettyfied output may sometimes contain empty lines which would
desynchonize the test monitor workers. The skipping code can be much
simplified though. Also a extract it so so that it's obvious what
it's doing and can be reused.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The test file can be broken up by newlines and is automatically
concatenated back. Fix the control flow so that the concatenation code
'continues' the loop rather than branching out.

Also add an anotation to the concatenation code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

On EOF, the loop can be terminated right away since most of it is
skipped anyways and the handling of the last command is repeated after
the loop.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The test data for capabilities is obtained from two consecutive qemu
runs when the regular monitor object will be reset. Do the same for the
test monitor object which is not disposed between runs by calling
qemuMonitorResetCommandID.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

qemucapabilitiestest for simplicity uses one test monitor object for
simulating work of two separate inquiries of the qemu process. To allow
better testing in the future it will be required to reset the counter
so that it accurately simulates how qemu would behave.

This patch adds a private monitor API which allows to reset the counter
which will be usable only in tests.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since virConfGetValueBool() can return earlier, the parameter 'value'
might be not initialised properly inside this method. Another proof:
Valgrind is returning this error during the libvirtd daemon startup:

==16199== Conditional jump or move depends on uninitialised value(s)
==16199==    at 0x27FFFEF4: virQEMUDriverConfigLoadFile (qemu_conf.c:809)
==16199==    by 0x2807665C: qemuStateInitialize (qemu_driver.c:654)
==16199==    by 0x5535428: virStateInitialize (libvirt.c:662)
==16199==    by 0x12AED8: daemonRunStateInit (remote_daemon.c:802)
==16199==    by 0x536DE18: virThreadHelper (virthread.c:206)
==16199==    by 0x6CB36DA: start_thread (pthread_create.c:463)
==16199==    by 0x6FEC88E: clone (clone.S:95)
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Move the code to a separate function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Formatting of 'driver' already used a separate buffer but was part of
the main function. Separate it and remove bunch of unnecessary temporary
variables.

Note that some checks are removed but they are not really necessary
anyways.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Extract and refactor the code to use the new approach which allows to
delete a monster condition to check if the element needs to be
formatted.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This patch implements the internal driver API for launch event into
qemu driver. When SEV is enabled, execute 'query-sev-launch-measurement'
to get the measurement of memory encrypted through launch sequence.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add remote support for launch security info.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The API can be used outside the libvirt to get the launch security
information. When SEV is enabled, the API can be used to get the
measurement of the launch process.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

QEMU >= 2.12 provides 'sev-guest' object which is used to launch encrypted
VMs on AMD platform using SEV feature. The various inputs required to
launch SEV guest is provided through the <launch-security> tag. A typical
SEV guest launch command line looks like this:

  -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 ...\
  -machine memory-encryption=sev0 \
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

QEMU uses /dev/sev device while creating the SEV guest, lets add /dev/sev
in the list of devices allowed to be accessed by the QEMU.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The launch-security element can be used to define the security
model to use when launching a domain. Currently we support 'sev'.

When 'sev' is used, the VM will be launched with AMD SEV feature enabled.
SEV feature supports running encrypted VM under the control of KVM.
Encrypted VMs have their pages (code and data) secured such that only the
guest itself has access to the unencrypted version. Each encrypted VM is
associated with a unique encryption key; if its data is accessed to a
different entity using a different key the encrypted guests data will be
incorrectly decrypted, leading to unintelligible data.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add remote support for virNodeGetSEVInfo().
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The API can be used by application to retrieve the Platform Diffie-Hellman
Key and Platform Certificate chain.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Extend hypervisor capabilities to include sev feature. When available,
hypervisor supports launching an encrypted VM on AMD platform. The
sev feature tag provides additional details like Platform Diffie-Hellman
(PDH) key and certificate chain which can be used by the guest owner to
establish a cryptographic session with the SEV firmware to negotiate
keys used for attestation or to provide secret during launch.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

QEMU version >= 2.12 provides support for launching an encrypted VMs on
AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
This patch adds support to query the SEV capability from the qemu.
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

And replace all calls with virObjectEventStateQueue such that:

    remoteEventQueue(priv, event, callbackID);

becomes:

    virObjectEventStateQueue(priv->eventState, event, callbackID);
Signed-off-by: NAnya Harter <aharter@redhat.com>

Remove NULL check around call to virObjectEventStateQueueRemote in
remote_driver.c.
Signed-off-by: NAnya Harter <aharter@redhat.com>

And remove NULL checking from all callers.
Signed-off-by: NAnya Harter <aharter@redhat.com>

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

When attaching a virtio-scsi with IOThreads for the config of a
live domain, allow the <address> to not be defined thus allowing
post parse processing to fill in the address. This allows parsing
of an individual device to succeed for attach config.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Make the error a bit clearer that virtio-scsi IOThreads require
virtio pci or ccw controller address types.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Fix the error message to indicate what exactly is failing - that
the controller index provided matches an existing controller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Commit id 1bd5a08d added a call to virXMLFormatElement without
also checking the return status.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

Commit id d8e8b63d introduced the test, but neglected to check for
error from virTestLoadFile in testCompareXMLToDomConfig.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

Introduced by commmit id 37bd4571. Need to goto cleanup and
not return directly.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

Commit id '7ef0471b' added a new parameter to qemuMonitorOpen,
but didn't update the ATTTRIBUTE_NONNULL for the @CB (param 5).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

The @disk was allocated, filled in, and consumed on the normal path,
but for error/cleanup paths it would be leaked.  Rename to newHardDisk
and manage properly.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

Need to free the allocated hardDiskToOpen array. The contents of the
array are just pointers returned by virVBoxSnapshotConfHardDiskByLocation
and not allocated AFAICT so they don't need to also be freed as well.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NKaterina Koukiou <kkoukiou@redhat.com>

s/glibc's_asprintf/glibc's asprintf
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>