Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

The function creates a list of all (or migratable only) CPU features
supported by QEMU. It works by looking at the CPU model info returned by
query-cpu-model-expansion QMP command.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

To make it more consistent with the rest of the CPU driver code.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

This is required for virCPUBaseline to accept a list of guest CPU
definitions since they do not have arch set.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

Modern host CPU models from domain capabilities XMLs are reported as
guest CPU definitions with feature policies. This patch updates
virCPUx86Baseline to properly handle such CPU models.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This command is a virsh wrapper for virConnectBaselineHypervisorCPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The new API computes the most feature-rich CPU which is compatible with
all given CPUs and can be provided by the specified hypervisor. It is a
more useful version of virConnectBaselineCPU, which doesn't consider any
hypervisor capabilities when computing the best CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This command is a virsh wrapper for virConnectCompareHypervisorCPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This new API compares the given CPU description with the CPU the
specified hypervisor is able to provide on the host. It is a more useful
version of virConnectCompareCPU, which compares the CPU definition with
the host CPU without considering any specific hypervisor and its
abilities.

https://bugzilla.redhat.com/show_bug.cgi?id=1559832
https://bugzilla.redhat.com/show_bug.cgi?id=1559835Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

virConnectGetDomainCapabilities needs to lookup QEMU capabilities
matching a specified binary, architecture, virt type, and machine type
while using default values when any of the parameters are not provided
by the user. Let's extract the lookup code into
virQEMUCapsCacheLookupDefault to make it reusable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The domain capabilities XML contains host CPU model tailored to a
specific hypervisor and since it's enclosed in <mode name='host-model'>
element rather then the required <cpu> it's impossible to directly use
the host CPU model as an input to, e.g., cpu-compare command. To make
this more convenient, vshExtractCPUDefXML now accepts full domain
capabilities XML and automatically transforms the host CPU models into
the form accepted by libvirt APIs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NKashyap Chamarthy <kchamart@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Both cpu-compare and cpu-baseline commands accept more that just CPU
definition XML(s). For users' convenience they are able to extract the
CPU definition(s) even from domain XML or capabilities XML. The main
differences between the two commands is in the number of CPU definitions
they expect: cpu-compare wants only one CPU definition while
cpu-baseline expects one or more CPUs.

The extracted code forms a new vshExtractCPUDefXML function.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Similarly to cpu-models these two commands do not operate on a domain
and should be listed in the "Host and Hypervisor" commands section.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The virDomainDetachDeviceAlias API is designed so that it only
sends detach request to qemu. It's user's responsibility to wait
for DEVICE_DELETED event, not libvirt's. Add @async flag to
qemuDomainDetach*Device() functions so that caller can chose if
detach is semi-synchronous (old virDomainDetachDeviceFlags()) or
fully asynchronous (new virDomainDetachDeviceFlags()).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The fact that we are overwriting @ret multiple times makes it
difficult to see what is actually happening here. Follow our
traditional pattern where @ret is initialized to -1, and set to 0
only in case we know we succeeded.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Funny, we obtain driver caps at the beginning of the function,
but then for unknown reason access driver->caps directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We are overwriting @ret a lot. It makes hard to see what is
actually going on. Use more gotos. Two functions are fixed here:
qemuDomainDetachShmemDevice() and qemuDomainDetachWatchdog().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

On watchdog unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:

1) release watchdog device address,
2) call qemuDomainRemoveWatchdog() which does 1) again.

This is potentially dangerous.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

On shmem unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:

1) release shmem device address,
2) call qemuDomainRemoveShmemDevice() which does 1) again.

This is potentially dangerous.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Instead of releasing address only sometimes in
qemuDomainDetachChrDevice() let's release it whenever the device
is actually removed from the domain definition.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When detaching a device it can be uniquely identified by its
alias. Instead of misusing virDomainDetachDeviceFlags which has
the same signature introduce new function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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

Commit id 'fe2af45b' added output for logical_block_size and
num_blocks for both removeable and fixed storage, but did not
update the nodedev capability causing virt-xml-validate to fail.
It's listed as optional only because it only prints if the
sizes are > 0. For a CDROM drive the values won't be formatted.

Update the nodedevxml2xmltest in order to output the values
for storage based on the logic from udevProcessRemoveableMedia
and udevProcessSD with respect to the logical_blocksize and
num_blocks calculations.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>

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

Commit id '02129b7c' added a single pagesElem for slightly
different purposes. One usage was an output for host page size
listing and the other for NUMA supported page sizes. For the
former, only the pages unit and size are formatted, while for
the latter the pages unit, size, and availability data is formatted.

The virt-xml-validate would fail because it expected something
extra in the host page size output. So split up pagesElem a bit
and create pagesHost and pagesNuma for the differences.

Modify some capabilityschemadata output to have the output - even
though the results may not be realistic with respect to the
original incarnation of the data.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>

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

Commit id 'd2440f3b' added printing the <microcode> for the
capabilities, but didn't update the capabilities schema.

While at it, update capabilityschemadata for caps-test2
and caps-test3 to output some value for validation.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>

Commit id '0eced74f' added vzmigr as a valid option for
virCapabilitiesAddHostMigrateTransport, but didn't update
the capabilities schema resulting in possible virt-xml-validate
failure.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>

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

Commit id 'b3fd95e3' added rdma as a valid option for
virCapabilitiesAddHostMigrateTransport, but didn't update
the capabilities schema resulting in possible virt-xml-validate
failure.

While at it, update the capabilityschemadata for caps-qemu-kvm
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>

Commit id 'e4938ce2' changed the esx_driver to use 'vpxmigr'
instead of esx for virCapabilitiesAddHostMigrateTransport, so
update the capabilities to allow virt-xml-validate to pass and
update the test to use the newer name.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>