Implementation for BP/libvirt-viommu-device.
With provide `hw:viommu_model` property to extra_specs or
`hw_viommu_model` to image property. will enable viommu to libvirt
guest.

[1] https://www.berrange.com/posts/2017/02/16/setting-up-a-nested-kvm-guest-for-developing-testing-pci-device-assignment-with-numa/
[2] https://review.opendev.org/c/openstack/nova-specs/+/840310

Implements: blueprint libvirt-viommu-device
Change-Id: Ief9c550292788160433a28a7a1c36ba38a6bc849
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

This change adds a new hw:locked_memory extra spec and hw_locked_memory
image property to contol preventing guest memory from swapping.

This change adds docs and extend the flavor
validators for the new extra spec.
Also add new image property.

Blueprint: libvirt-viommu-device
Change-Id: Id3779594f0078a5045031aded2ed68ee4301abbd

Add the `hw_ephemeral_encryption` and `hw_ephemeral_encryption_format`
image properties.

Change-Id: Ida3edbdd664fbc3ac23516b1ff5b67edae43ea79

arch in libvirt driver support

This is split 1 of 3 for the architecture emulation feature.

This adds the 'hw_emulation_architecture' property to the image meta
properties, allowing for operator to define whether they will use
emulation or not.

This adds the capability as a feature to ensure no impact to normal
operations or functionality.

Account for object versioning has been added to raise exceptions and
handle proper

Implements: blueprint pick-guest-arch-based-on-host-arch-in-libvirt-driver
Signed-off-by: Jonathan Race <jrace@augusta.edu>
Change-Id: If4f598c0d3f9e64617beb54450faa04e7d20dd20

The 'bochs' display device is a recommended[1] safe option for UEFI
guests.  This is supported in libvirt from version 5.6.0; Nova's current
MIN_LIBVIRT_VERSION (6.0.0) satisfies this requirement.

Partially quoting the "bochs display device" section from a post written
by a QEMU graphics maintainer[1]:

    [...] Main advantage over standard VGA is that this device is alot
    simpler.  The code size and complexity needed to emulate this device
    is an order of magnitude smaller, resulting in a reduced attack
    surface. Another nice feature is that you can place this device in a
    PCI Express slot.

    For UEFI guests it is safe to use the bochs display device instead
    of the standard VGA device. The firmware will setup a linear
    framebuffer as GOP anyway and never use any legacy VGA features.

    For BIOS guests this device might be useable as well, depending on
    whenever they depend on direct VGA hardware access or not. There is
    a vgabios which supports text rendering on a linear framebuffer, so
    software which uses the vgabios services for text output will
    continue to work. Linux bootloaders typically fall into this
    category. The linux text mode console (vgacon) uses direct hardware
    access and does not work. The framebuffer console (fbcon running on
    vesafb or bochs-drm) works.

[1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/

Implements: blueprint add-bochs-display-device

Change-Id: Id194028f5d2cbaac1c5e699b71fd9751f87f5da5
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>

The USB-based tablet is often the only USB device in an x86 instance,
while the USB-based keyboard is often the only such device in an AArch64
instance (x86 have PS2 keyboards and mice). Replacing these with
virtio-based devices can eliminate the need to have a USB host adapter
in the instance. Enable just that possibility by adding a new value
image metadata property, 'hw_input_bus'. This allows us to specify not
only virtio-based pointer and keyboard input devices but also USB
equivalents.

Note that this also fixes one instance of a particular class of bugs,
whereby we have checks for *guest* architecture-specific behavior that
are being toggled based on the *host* architecture. In this instance,
we were attempting to add a keyboard device on AArch64 guests since they
don't have one by default, but we were determining the architecture by
looking at the CPU architecture reported in the host capabilities. By
replacing this check of the host capabilities with a call to the
'nova.virt.libvirt.utils.get_arch' helper, we correctly handle requests
to create non-host architecture guests via the 'hw_architecture' image
metadata property. There are many other instances of this bug and those
can be resolved separately.

Change-Id: If9f3ede3e8449f9a6c8d1da927974c0a73923d51
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

This patch adds the 'socket' value to the allowed PCI NUMA affinity
policies, both to the 'hw:pci_numa_affinity_policy' flavor extra spec,
and the 'hw_pci_numa_affinity_policy' image property.

For now the new value is a no-op and remains undocumented. It will be
wired-in in a subsequent patch.

Implements: blueprint pci-socket-affinity
Change-Id: I0680d4e21f3e317ac702b55afef4c87e8acbfc3a

Add support for the 'hw:tpm_version' and 'hw:tpm_model' flavor extra
specs along with the equivalent image metadata properties. These are
picked up by the scheduler and transformed into trait requests. This is
effectively a no-op for now since we don't yet have a driver that
reports these traits.

Part of blueprint add-emulated-virtual-tpm

Change-Id: I8645c31b4ecb18afea592b2a5b360b0165626009
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Introduce a 'mixed' instance CPU allocation policy and
will be worked with upcoming patches, for purpose of
creating an instance combined shared CPUs with dedicated
or realtime CPUs.

In an instance mixed with different type of CPUs, the shared CPU
shared CPU time slots with other instances, and also might be a
CPU with less or un-guaranteed hardware resources, which implies
to have no guarantee for the behavior of the workload running on
it. If we call the shared CPU as 'low priority' CPU, then the
realtime or dedicated CPU could be called as 'high priority' CPU,
user could assign more hardware CPU resources or place some
guaranteed resource to it to let the workload to entail high
performance or stable service quality.

Based on https://review.opendev.org/714704

Part of blueprint use-pcpu-and-vcpu-in-one-instance

Change-Id: I99cfee14bb105a8792651129426c0c5a3749796d
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>