[PATCH v2 0/4] VirtioNet RSS support.
by Andrew Melnychenko
This series of patches add RSS property support for virtio-net-pci.
Virtio RSS effectively works with TAP devices, it requires additional
vectors for VirtioNet, queues for TAP device, and vCPU cores.
Example of device configuration:
```
<interface type="network">
<mac address="52:54:00:c4:90:25"/>
<source network="default"/>
<model type="virtio"/>
<driver name="qemu" queues="9" rss="on" rss_hash_report="off"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
```
Capability "rss" enables RSS, "rss_hash_report" - enables hashes in vheader.
For now, "rss" property will trigger "in-qemu" RSS in most cases.
Current Qemu(6.2) supports eBPF RSS that may require additional capabilities.
In future, the helper will be provided. And this code is the base for VirtIO RSS.
Changes since v1:
* refactored patches
* changed docs and tests
Changes since RFC:
* rebased and refactored
* added tests
* postponed the helper
Andrew Melnychenko (4):
domain_conf: Added configs for RSS and Hash report.
qemu_capabilities: Added capabilites for qemu's "rss" and "hash".
qemu_command: Added "rss" and "hash" properties.
test: Added xml2argv and xml2xml tests.
docs/formatdomain.rst | 18 ++++++++
docs/schemas/domaincommon.rng | 10 +++++
src/conf/domain_conf.c | 31 ++++++++++++-
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 2 +
src/qemu/qemu_validate.c | 14 ++++++
.../caps_5.1.0.x86_64.xml | 1 +
.../caps_5.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 +
.../caps_5.2.0.riscv64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 +
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 1 +
.../caps_6.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 +
.../caps_6.2.0.x86_64.xml | 1 +
.../net-virtio-rss.x86_64-latest.args | 43 +++++++++++++++++++
tests/qemuxml2argvdata/net-virtio-rss.xml | 39 +++++++++++++++++
.../virtio-options.x86_64-latest.args | 2 +-
tests/qemuxml2argvdata/virtio-options.xml | 2 +-
tests/qemuxml2argvtest.c | 2 +
26 files changed, 178 insertions(+), 3 deletions(-)
create mode 100644 tests/qemuxml2argvdata/net-virtio-rss.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/net-virtio-rss.xml
--
2.34.1
2 years, 1 month
libvirt: introduce VIR_DOMAIN_DESTROY_REMOVE_LOGS flag
by Nikolay Shirokovskiy
The patch series based on discussion in RFC [1].
I wonder if we'd better add some property like "transient logs" instead
of adding a flag to destoy API.
Yes libguestfs uses virDomainDestroyFlags to terminate a VM and it is
intended client of this new flag but it or other clients may want to use
shutdown API or use autodestroy domains with same log behaviour. Then
for the current task we only need to support this property in domain xml
I guess.
[1] removing VMs logs
https://listman.redhat.com/archives/libvir-list/2022-February/msg00273.html
Nikolay Shirokovskiy (3):
libvirt: introduce VIR_DOMAIN_DESTROY_REMOVE_LOGS flag
qemu: support VIR_DOMAIN_DESTROY_REMOVE_LOGS flag
tools: support --remove-logs flag on destroing domain
docs/manpages/virsh.rst | 7 +++++-
include/libvirt/libvirt-domain.h | 1 +
src/libvirt-domain.c | 6 +++++
src/qemu/qemu_domain.c | 41 ++++++++++++++++++++++++++++++++
src/qemu/qemu_domain.h | 4 ++++
src/qemu/qemu_driver.c | 8 ++++++-
tools/virsh-domain.c | 8 ++++++-
7 files changed, 72 insertions(+), 3 deletions(-)
--
2.31.1
2 years, 1 month
[PATCH v2 00/19] Refactoring conf to use XPath
by Kristina Hanicova
This is v2 from
https://listman.redhat.com/archives/libvir-list/2021-April/msg00617.html
Changes since v1:
- rebase to the lastest git master
This series reworks the outdated way of parsing XML to parsing by XPath,
which is more obvious and saves a few lines of code.
Kristina Hanicova (19):
conf: Propagate xmlXPathContextPtr into
virDomainHostdevSubsysUSBDefParseXML()
Refactoring virDomainHostdevSubsysUSBDefParseXML() to use XPath
conf: Propagate xmlXPathContextPtr into virDomainBlkioDeviceParseXML()
Refactoring virDomainBlkioDeviceParseXML() to use XPath
conf: Propagate xmlXPathContextPtr into
virDomainHostdevSubsysPCIDefParseXML()
Refactoring virDomainHostdevSubsysPCIDefParseXML() to use XPath
conf: Propagate xmlXPathContextPtr into virDomainLeaseDefParseXML()
Refactoring virDomainLeaseDefParseXML() to use XPath
Refactoring virDomainFSDefParseXML() to use XPath
Refactoring virDomainNetDefParseXML() to use XPath
conf: Propagate xmlXPathContextPtr into
virDomainChrDefParseTargetXML()
Refactoring virDomainChrDefParseTargetXML() to use XPath
Refactoring virDomainChrSourceDefParseXML() to use XPath
Refactoring virDomainChrDefParseXML() to use XPath
Refactoring virDomainSmartcardDefParseXML() to use XPath
Refactoring virDomainGraphicsDefParseXMLSpice() to use XPath
conf: Propagate xmlXPathContextPtr into
virDomainVideoDriverDefParseXML()
Refactoring virDomainVideoDriverDefParseXML() to use XPath
Refactoring virDomainVideoDefParseXML() to use XPath
src/conf/domain_conf.c | 1641 +++++++++++++++++-----------------------
1 file changed, 707 insertions(+), 934 deletions(-)
--
2.30.2
2 years, 1 month
[libvirt][PATCH RESEND v10 0/5] Support query and use SGX
by Haibin Huang
Because the 5th patch was sent by mistake, so replace the 5th patch and
send it again.
This patch series provides support for enabling Intel's Software
Guard Extensions (SGX) feature in guest VM.
Giving the SGX support in QEMU had been merged. Intel SGX is a
set of instructions that increases the security of application code
and data, giving them more protection from disclosure or modification.
Developers can partition sensitive information into enclaves, which
are areas of execution in memory with more security protection.
It depends on QEMU fixing[1], which will move cpu QOM object from
/machine/unattached/device[nn] to /machine/cpu[nn]. It requires libvirt
to change the default cpu QOM object location once QEMU patch gets
accepted, but it is out of this SGX patch scope.
The typical flow looks below at very high level:
1. Calls virConnectGetDomainCapabilities API to domain capabilities
that includes the following SGX information.
<feature>
...
<sgx supported='yes'>
<epc_size unit='KiB'>N</epc_size>
</sgx>
...
</feature>
2. User requests to start a guest calling virCreateXML() with SGX
requirement. It does not support NUMA yet, since latest QEMU 6.2
release does not support NUMA.
It should contain
<devices>
...
<memory model='sgx-epc'>
<target>
<size unit='KiB'>N</size>
</target>
</memory>
...
</devices>
[1] https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg03534.html
Haibin Huang (3):
qemu: provide support to query the SGX capability
conf: expose SGX feature in domain capabilities
Add unit test for domaincapsdata sgx
Lin Yang (2):
conf: Introduce SGX EPC element into device memory xml
Update default CPU location in qemu QOM tree
docs/formatdomain.rst | 9 +-
docs/formatdomaincaps.html.in | 26 ++++
docs/schemas/domaincaps.rng | 22 ++-
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_capabilities.c | 29 ++++
src/conf/domain_capabilities.h | 13 ++
src/conf/domain_conf.c | 6 +
src/conf/domain_conf.h | 1 +
src/conf/domain_validate.c | 16 ++
src/libvirt_private.syms | 1 +
src/qemu/qemu_alias.c | 3 +
src/qemu/qemu_capabilities.c | 137 ++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_capspriv.h | 4 +
src/qemu/qemu_command.c | 1 +
src/qemu/qemu_domain.c | 38 +++--
src/qemu/qemu_domain_address.c | 6 +
src/qemu/qemu_driver.c | 1 +
src/qemu/qemu_monitor.c | 10 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 84 ++++++++++-
src/qemu/qemu_monitor_json.h | 9 ++
src/qemu/qemu_process.c | 2 +
src/qemu/qemu_validate.c | 8 +
src/security/security_apparmor.c | 1 +
src/security/security_dac.c | 2 +
src/security/security_selinux.c | 2 +
tests/domaincapsdata/bhyve_basic.x86_64.xml | 1 +
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 1 +
tests/domaincapsdata/bhyve_uefi.x86_64.xml | 1 +
tests/domaincapsdata/empty.xml | 1 +
tests/domaincapsdata/libxl-xenfv.xml | 1 +
tests/domaincapsdata/libxl-xenpv.xml | 1 +
.../domaincapsdata/qemu_2.11.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.11.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.11.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.11.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.12.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.12.0-tcg.x86_64.xml | 1 +
.../qemu_2.12.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_2.12.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_2.12.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_2.12.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.12.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.4.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.4.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.4.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.5.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.5.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.5.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.6.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.6.0-tcg.x86_64.xml | 1 +
.../qemu_2.6.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_2.6.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_2.6.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_2.6.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.7.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.7.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.7.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.7.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.8.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.8.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.8.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.8.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.9.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.9.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_2.9.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_2.9.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_2.9.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.0.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.0.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_3.0.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_3.0.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_3.0.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.1.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_3.1.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_3.1.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.0.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 1 +
.../qemu_4.0.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_4.0.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_4.0.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_4.0.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 +
.../qemu_4.2.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 1 +
.../qemu_5.0.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_5.1.0.sparc.xml | 1 +
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 1 +
.../qemu_5.2.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 1 +
.../qemu_6.0.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 +
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 1 +
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1 +
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 4 +
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 4 +
.../qemu_6.2.0-virt.aarch64.xml | 1 +
tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 1 +
tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 4 +
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 4 +
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 4 +
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 1 +
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 4 +
.../caps_6.2.0.x86_64.replies | 22 ++-
.../caps_6.2.0.x86_64.xml | 5 +
.../caps_7.0.0.x86_64.replies | 22 ++-
.../caps_7.0.0.x86_64.xml | 5 +
tests/qemuxml2argvdata/sgx-epc.xml | 36 +++++
.../sgx-epc.x86_64-latest.xml | 52 +++++++
tests/qemuxml2xmltest.c | 2 +
138 files changed, 675 insertions(+), 30 deletions(-)
create mode 100644 tests/qemuxml2argvdata/sgx-epc.xml
create mode 100644 tests/qemuxml2xmloutdata/sgx-epc.x86_64-latest.xml
--
2.17.1
2 years, 2 months
REST service for libvirt to simplify SEV(ES) launch measurement
by Daniel P. Berrangé
Extending management apps using libvirt to support measured launch of
QEMU guests with SEV/SEV-ES is unreasonably complicated today, both for
the guest owner and for the cloud management apps. We have APIs for
exposing info about the SEV host, the SEV guest, guest measurements
and secret injections. This is a "bags of bits" solution. We expect
apps to them turn this into a user facting solution. It is possible
but we're heading to a place where every cloud mgmt app essentially
needs to reinvent the same wheel and the guest owner will need to
learn custom APIs for dealing with SEV/SEV-ES for each cloud mgmt
app. This is pretty awful. We need to do a better job at providing
a solution that is more general purpose IMHO.
Consider a cloud mgmt app, right now the flow to use the bag of
bits libvirt exposes, looks something like
* Guest owner tells mgmt app they want to launch a VM
* Mgmt app decides what host the VM will be launched on
* Guest owner requests cert chain for the virt host from mgmt app
* Guest owner validates cert chain for the virt host
* Guest owner generates launch blob for the VM
* Guest owner provides launch blob to the mgmt app
* Management app tells libvirt to launch VM with blob,
with CPUs in a paused state
* Libvirt luanches QEMU with CPUs stopped
* Guest owner requests launch measurement from mgmt app
* Guest owner validates measurement
* Guest owner generates secret blob
* Guest owner sends secret blob to management app
* Management app tells libvirt to inject secrets
* Libvirt injects secrets to QEMU
* Management app tells libvirt to start QEMU CPUs
* Libvirt tells QEMU to start CPUs
Compare to a non-confidental VM
* Guest owner tells mgmt app they want to launch a VM
* Mgmt app decides what host the VM will be launched on
* Mgmt app tells libvirt to launch VM with CPUs in running state
* Libvirt launches QEMU with CPUs running
Now, of course the guest owner wouldn't be manually performing the
earlier steps, they would want some kind of software to take care
of this. No matter what, it still involves a large number of back
and forth operations between the guest owner & mgmt app, and between
the mgmt app and libvirt.
One of libvirt's key jobs is to isolate mgmt apps from differences
in behaviour of underlying hypervisor technologies, and we're failing
at that job with SEV/SEV-ES, because the mgmt app needs to go through
a multi-stage dance on every VM start, that is different from what
they do with non-confidential VMs.
It is especially unpleasant because there needs to be a "wait state"
between when the app selects a host to deploy a VM on, and when it
can actually start a VM. In essence the app needs to reserve capacity
on a host ahead of time for a VM that will be created some arbitrary
time later. This can have significant implications for the mgmt app
architectural design that are not neccessarily easy to address, when
they expect to just call virDomainCreate have the VM running in one
step.
It also harms interoperability to libvirt tools. For example if
a mgmt tool like virt-manager/OpenStack created a VM using SEV,
and you want to start it manually using a different tool like
'virsh', you enter a world of complexity and pain, due to the
multi step dance required.
AFAICT, in all of this, the mgmt app is really acting as a conduit
and is not implementing any interesting logic. The clever stuff is
all the responsibility of the guest owner, and/or whatever software
for attestation they are using remotely.
I think there is scope for enhancing libvirt, such that usage of
SEV/SEV-ES has little-to-no burden for the management apps, and
much less burden for guest owners. The key to achieving this is
to define a protocol for libvirt to connect to a remote service
to handle the launch measurements & secret acquisition. The guest
owner can provide the address of a service they control (or trust),
and libvirt can take care of all the interactions with it.
This frees both the user and mgmt app from having to know much
about SEV/SEV-ES, with VM startup process being essentially the
same as it has always been.
The sequence would look like
* Guest owner tells attestation service they intend to
create a VM with a given UUID, policy, and any other
criteria such as cert of the cloud owner, valid OVMF
firmware hashes, and providing any needed LUKS keys.
* Guest owner tells mgmt app they want to launch a VM,
using attestation service at https://somehost/and/url
* Mgmt app decides what host the VM will be launched on
* Mgmt app tells libvirt to launch VM with CPUs in running state
The next steps involve solely libvirt & the attestation service.
The mgmt app and guest owner have done their work.
* Libvirt contacts the service providing certificate chain
for the host to be used, the UUID of the guest, and any
other required info about the host.
* Attestation service validates the cert chain to ensure
it belongs to the cloud owner that was identified previously
* Attestation service generates a launch blob and puts it in
the response back to libvirt
* Libvirt launches QEMU with CPUs paused
* Libvirt gets the launch measurement and sends it to the
attestation server, with any other required info about the
VM instance
* Attestation service validates the measurement
* Attestation builds the secret table with LUKS keys
and puts it in the response back to libvirt
* Libvirt injects the secret table to QEMU
* Libvirt tells QEMU to start CPUs
All the same exchanges of information are present, but the management
app doesn't have to get involved. The guest owner also doesn't have
to get involved except for a one-time setup step. The software the
guest owner uses for attestation also doesn't have to be written to
cope with talking to OpenStack, CNV and whatever other vendor specific
cloud mgmt apps exist today. This will significantly reduce the burden
if supporting SEV/SEV-ES launch measurement in libvirt based apps, and
make SEV/SEV-ES guests more "normal" from a mgmt POV.
What could this look like from POV of an attestation server API, if
we assume HTTPS REST service with a simple JSON payload ...
* Guest Owner: Register a new VM to be booted:
POST /vm/<UUID>
Request body:
{
"scheme": "amd-sev",
"cloud-cert": "certificate of the cloud owner that signs the PEK",
"policy": 0x3,
"cpu-count": 3,
"firmware-hashes": [
"xxxx",
"yyyy",
],
"kernel-hash": "aaaa",
"initrd-hash": "bbbb",
"cmdline-hash": "cccc",
"secrets": [
{
"type": "luks-passphrase",
"passphrase": "<blah>"
}
]
}
* Libvirt: Request permission to launch a VM on a host
POST /vm/<UUID>/launch
Request body:
{
"pdh": "<blah>",
"cert-chain": "<blah>",
"cpu-id": "<CPU ID>",
...other relevant bits...
}
Service decides if the proposed host is acceptable
Response body (on success)
{
"session": "<blah>",
"owner-cert": "<blah>",
"policy": 3,
}
* Libvirt: Request secrets to inject to launched VM
POST /vm/<UUID>/validate
Request body:
{
"api-minor": 1,
"api-major": 2,
"build-id": 241,
"policy": 3,
"measurement": "<blah>",
"firmware-hash": "xxxx",
"cpu-count": 3,
....other relevant stuff....
}
Service validates the measurement...
Response body (on success):
{
"secret-header": "<blah>",
"secret-table": "<blah>",
}
So we can see there are only a couple of REST API calls we need to be
able to define. If we could do that then creating a SEV/SEV-ES enabled
guest with libvirt would not involve anything more complicated for the
mgmt app that providing the URI of the guest owner's attestation service
and an identifier for the VM. ie. the XML config could be merely:
<launchSecurity type="sev">
<attestation vmid="57f669c2-c427-4132-bc7a-26f56b6a718c"
service="http://somehost/some/url"/>
</launchSecurity>
And then involve virDomainCreate as normal with any other libvirt / QEMU
guest. No special workflow is required by the mgmt app. There is a small
extra task for the guest owner to register existance of their VM with the
attestation service. Aside from that the only change to the way they
interact with the cloud mgmt app is to provide the VM ID and URI for the
attestation service. No need to learn custom APIs for each different
cloud vendor, for dealing with fetching launch measurements or injecting
secrets.
Finally this attestation service REST protocol doesn't have to be something
controlled or defined by libvirt. I feel like it could be a protocol that
is defined anywhere and libvirt merely be one consumer of it. Other apps
that directly use QEMU may also wish to avail themselves of it.
All that really matters from libvirt POV is:
- The protocol definition exist to enable the above workflow,
with a long term API stability guarantee that it isn't going to
changed in incompatible ways
- There exists a fully open source reference implementation of sufficient
quality to deploy in the real world
I know https://github.com/slp/sev-attestation-server exists, but its current
design has assumptions about it being used with libkrun AFAICT. I have heard
of others interested in writing similar servers, but I've not seen code.
We are at a crucial stage where mgmt apps are looking to support measured
boot with SEV/SEV-ES and if we delay they'll all go off and do their own
thing, and it'll be too late, leading to https://xkcd.com/927/.
Especially for apps using libvirt to manage QEMU, I feel we have got a
few months window of opportunity to get such a service available, before
they all end up building out APIs for the tedious manual workflow,
reinventing the wheel.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2 years, 2 months
[PATCH v3 00/29] ppc64 PowerNV machines support
by Daniel Henrique Barboza
Hi,
This new version contains changes proposed by Jano. The most notable
change is on patch 9, where pnv_pnv3/pnv_phb4 capabilities are now being
probed and, if the QEMU version isn't high enough, they are cleared from
qemuCaps.
For convenience, the patches that are pending review/acks are patches 14,
17, 19, 20, 22, 23 and 24.
v2 link: https://listman.redhat.com/archives/libvir-list/2022-January/msg01149.html
Daniel Henrique Barboza (29):
qemu_domain.c: add PowerNV machine helpers
qemu_capabilities.c: use 'MachineIsPowerPC' in DeviceDiskCaps
qemu_domain: turn qemuDomainMachineIsPSeries() static
qemu_validate.c: use qemuDomainIsPowerPC() in
qemuValidateDomainChrDef()
qemu_domain.c: define ISA as default PowerNV serial
qemu_validate.c: enhance 'machine type not supported' message
qemu_domain.c: disable default devices for PowerNV machines
tests: add basic PowerNV8 test
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB3
conf, qemu: add 'pnv-phb3-root-port' PCI controller model name
conf, qemu: add 'pnv-phb3' PCI controller model name
domain_conf.c: fix identation in virDomainControllerDefParseXML()
conf: parse and format <target chip-id='...'/>
formatdomain.rst: add 'index' semantics for PowerNV domains
conf: introduce virDomainControllerIsPowerNVPHB
conf, qemu: add default 'chip-id' value for pnv-phb3 controllers
conf, qemu: add default 'targetIndex' value for pnv-phb3 devs
qemu_command.c: add command line for the pnv-phb3 device
qemu_domain_address.c: change pnv-phb3 minimal downstream slot
domain_conf: always format pnv-phb3-root-port address
tests: add pnv-phb3-root-port test
domain_validate.c: allow targetIndex 0 out of idx 0 for PowerNV PHBs
domain_conf.c: reject duplicated pnv-phb3 devices
qemu: introduce QEMU_CAPS_DEVICE_PNV_PHB4
conf, qemu: add 'pnv-phb4-root-port' PCI controller model name
domain_conf.c: add phb4-root-port to IsPowerNVRootPort()
conf, qemu: add 'pnv-phb4' controller model name
domain_conf.c: add pnv-phb4 to ControllerIsPowerNVPHB()
tests: add PowerNV9 tests
docs/formatdomain.rst | 12 +-
docs/schemas/domaincommon.rng | 10 ++
src/conf/domain_conf.c | 156 ++++++++++++++----
src/conf/domain_conf.h | 8 +
src/conf/domain_validate.c | 5 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 19 ++-
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 21 ++-
src/qemu/qemu_domain.c | 51 +++++-
src/qemu/qemu_domain.h | 4 +-
src/qemu/qemu_domain_address.c | 64 ++++++-
src/qemu/qemu_validate.c | 62 ++++++-
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 +
.../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 +
.../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 2 +
.../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 2 +
.../powernv8-basic.ppc64-latest.args | 34 ++++
tests/qemuxml2argvdata/powernv8-basic.xml | 16 ++
tests/qemuxml2argvdata/powernv8-dupPHBs.err | 1 +
.../powernv8-dupPHBs.ppc64-latest.err | 1 +
tests/qemuxml2argvdata/powernv8-dupPHBs.xml | 27 +++
.../powernv8-root-port.ppc64-latest.args | 35 ++++
tests/qemuxml2argvdata/powernv8-root-port.xml | 17 ++
.../powernv8-two-sockets.ppc64-latest.args | 35 ++++
.../qemuxml2argvdata/powernv8-two-sockets.xml | 26 +++
.../powernv9-dupPHBs.ppc64-latest.err | 1 +
tests/qemuxml2argvdata/powernv9-dupPHBs.xml | 27 +++
.../powernv9-root-port.ppc64-latest.args | 35 ++++
tests/qemuxml2argvdata/powernv9-root-port.xml | 17 ++
tests/qemuxml2argvtest.c | 7 +
.../powernv8-basic.ppc64-latest.xml | 34 ++++
.../powernv8-root-port.ppc64-latest.xml | 39 +++++
.../powernv8-two-sockets.ppc64-latest.xml | 39 +++++
.../powernv9-root-port.ppc64-latest.xml | 39 +++++
.../qemuxml2xmloutdata/powernv9-root-port.xml | 36 ++++
tests/qemuxml2xmltest.c | 5 +
37 files changed, 848 insertions(+), 48 deletions(-)
create mode 100644 tests/qemuxml2argvdata/powernv8-basic.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/powernv8-basic.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.err
create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.ppc64-latest.err
create mode 100644 tests/qemuxml2argvdata/powernv8-dupPHBs.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/powernv8-root-port.xml
create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/powernv8-two-sockets.xml
create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.ppc64-latest.err
create mode 100644 tests/qemuxml2argvdata/powernv9-dupPHBs.xml
create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/powernv9-root-port.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-basic.ppc64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-root-port.ppc64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv8-two-sockets.ppc64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.ppc64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/powernv9-root-port.xml
--
2.35.1
2 years, 2 months
[libvirt PATCH v2 0/6] Add support for 'blob' to virtio video device
by Jonathon Jongsma
Add support to libvirt for the 'blob' option for virtio video devices in qemu.
Also do a little preparatory refactoring of the video device xml parsing code.
Changes in v2:
- Added some basic documentation
- add a qemu capability
- Make sure that the /dev/udmabuf device is accessible to qemu (cgroups, etc)
Jonathon Jongsma (6):
conf: Refactor video model parsing
conf: switch to virXMLProp* functions
conf: use enum variable for video type
conf: add support for 'blob' in virtio video device
qemu: Add capability for virtio-gpu.blob
qemu: Implement 'blob' support for virtio gpu
docs/formatdomain.rst | 6 +
docs/schemas/domaincommon.rng | 5 +
src/conf/domain_conf.c | 133 +++++++++---------
src/conf/domain_conf.h | 3 +-
src/conf/domain_validate.c | 13 +-
src/libxl/libxl_conf.c | 10 ++
src/libxl/libxl_domain.c | 11 ++
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_cgroup.c | 28 ++--
src/qemu/qemu_command.c | 3 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_monitor_json.c | 16 ++-
src/qemu/qemu_namespace.c | 22 +++
src/qemu/qemu_process.c | 7 +
src/qemu/qemu_validate.c | 9 ++
.../caps_6.1.0.x86_64.xml | 1 +
.../caps_6.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 +
.../caps_6.2.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 +
.../caps_7.0.0.x86_64.xml | 1 +
.../video-virtio-blob-absent.args | 34 +++++
.../video-virtio-blob-absent.xml | 33 +++++
.../video-virtio-blob-off.args | 34 +++++
.../video-virtio-blob-off.xml | 33 +++++
.../video-virtio-blob-on.args | 34 +++++
.../qemuxml2argvdata/video-virtio-blob-on.xml | 33 +++++
.../video-virtio-vga-blob-on.args | 34 +++++
.../video-virtio-vga-blob-on.xml | 33 +++++
tests/qemuxml2argvtest.c | 12 ++
.../video-virtio-blob-absent.xml | 41 ++++++
.../video-virtio-blob-off.xml | 41 ++++++
.../video-virtio-blob-on.xml | 41 ++++++
.../video-virtio-vga-blob-on.xml | 41 ++++++
tests/qemuxml2xmltest.c | 12 ++
36 files changed, 652 insertions(+), 84 deletions(-)
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.args
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.xml
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.args
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.xml
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.args
create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.xml
create mode 100644 tests/qemuxml2argvdata/video-virtio-vga-blob-on.args
create mode 100644 tests/qemuxml2argvdata/video-virtio-vga-blob-on.xml
create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-absent.xml
create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-off.xml
create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-on.xml
create mode 100644 tests/qemuxml2xmloutdata/video-virtio-vga-blob-on.xml
--
2.35.1
2 years, 2 months
[libvirt PATCH] spec: Move virkey* manual pages from -daemon to -client
by Andrea Bolognani
The documentation included in these manual pages is mostly useful
to users of the 'send-key' virsh command, and the virsh manual
page refers to them, so it makes more sense to install them along
with virsh instead of libvirtd.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
libvirt.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 0e6cd13bb2..6855b3a760 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1733,7 +1733,6 @@ exit 0
%{_mandir}/man8/virtlogd.8*
%{_mandir}/man8/virtlockd.8*
%{_mandir}/man8/virtproxyd.8*
-%{_mandir}/man7/virkey*.7*
%{_bindir}/virt-host-validate
%{_bindir}/virt-admin
@@ -2010,6 +2009,7 @@ exit 0
%{_mandir}/man1/virt-xml-validate.1*
%{_mandir}/man1/virt-pki-query-dn.1*
%{_mandir}/man1/virt-pki-validate.1*
+%{_mandir}/man7/virkey*.7*
%{_bindir}/virsh
%{_bindir}/virt-xml-validate
%{_bindir}/virt-pki-query-dn
--
2.34.1
2 years, 2 months
[libvirt PATCH 0/4] [RFC] Functional CI - GitLab enablement
by Erik Skultety
I'd like to propose a PoC of a GitLab-driven functional CI based on GitLab's
custom executor runner feature.
** TL;DR **
- there's some RH owned HW that can be utilized for upstream functional CI
running workloads on Red Hat-sponsored distros (see the pipeline)
- the PoC utilizes GitLab's custom executor feature [1] which allows literally
any infrastructure to be plugged into the CI machinery
- the PoC solution (as proposed) is relying on nested virt capability and
backed by plain libvirt + QEMU/KVM
- the test environment comprises of the libvirt-TCK suite [2] and Avocado test
framework [3] as the harness engine (as a wrapper and future replacement of
the existing Perl implementation)
- example pipeline (simplified to only a couple of distros) can be found here [4]
- libvirt debug logs are exposed as artifacts and can be downloaded on job
failure
** LONG VERSION **
This RFC is driven by GitLab's custom executor feature which can be integrated
with any VMM and hence libvirt+QEMU/KVM as well. Example pipeline can be found
here [4].
Architecture
============
Platform
~~~~~~~~
It doesn't matter what platform is used with this PoC, but FWIW the one tested
with this PoC is a baremetal KVM virtualization host provided and owned by
Red Hat, utilizing libvirt, QEMU, a bit of lcitool [5], and libguestfs.
Custom executor
~~~~~~~~~~~~~~
If you're wondering why this PoC revolves around the custom executor GitLab
runner type [6], some time ago GitLab decided that instead of adding and
supporting different types of virtualization runners, they'd create some kind
of gateway suitable basically for any solution out there and named it 'custom
executor' - it's nothing more than a bunch of shell scripts categorized to
various stages of a pipeline job (which will run either on the host or the
guest depending how you set it up).
Provisioner
~~~~~~~~~~~
Wait, why is this section needed, just take the example scripts from [1]...
If you look at the example Bash scripts in GitLab's docs on custom executor [1]
you'll see that the example scripts are very straight forward and concise but
there are few things that are suboptimal
- creating a new disk image for every single VM instance of the same distro out
of the virt-builder template
- injecting a bunch of commands directly with virt-builder instead of using
something more robust like Ansible when there is more than a single VM to be
created
- static hostname for every single VM instance
- waiting for the either the VM getting an IP or for the SSH connection to be
available for a quite limited fixed period of time
Because I wanted to address all of the ^above pitfalls, I created a Python
based provisioner relying on libvirt-NSS, transient machines,
backing chain overlay images, cloud-init, etc. instead. You can find the code
base for the provisioner here [7].
Child pipelines & Multiproject CI pipelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
child pipeline = a "downstream" (or subpipeline) of the main pipeline useful
when there are multiple stages which should be part of a
single stage of the main pipeline
multiproject pipeline = a pipeline that is kicked off by the main pipeline of
your project and runs in context of a different project
which your main pipeline can then depend on
Technically speaking none of the above 2 GitLab features is needed to really
integrate this PoC to upstream libvirt CI, but it was a nice experiment from 3
perspectives:
1) seeing that GitLab's own public SaaS deployment has features from all
tiers available
2) it made some job descriptions shorter because e.g. we didn't have to
rebuild libvirt in the VM when it was done in the previous step in a
container; we don't need to build the Perl bindings (which we need for
libvirt-TCK) in the VM either, since we already have a project and hence
a pipeline for that already, we just need to harness the results which
combined makes the actual VM's purpose more obvious
3) installing libvirt and libvirt-perl using the RPM artifacts built in
previous pipeline stages is closer to a real life deployment/environment
than re-building everything in the VM followed by doing
'sudo make install'
Artifacts
~~~~~~~~~
Apart from the RPMs being published as artifacts from an earlier stage of the
pipeline as mentioned in the previous section, in order for this to be any
useful to the developers (I know, NOTHING beats a local setup, just be patient
with us/me for another while...), when there's a genuine test failure (no
infrastructure is failproof), the job description as proposed in patch 4/5
exposes libvirt debug logs as artifacts which can be downloaded and inspected.
Test framework
==============
For the SW testing part a combination of libvirt-TCK [2] and Avocado [3] were
used. The reasoning for this combined test environment was discussed in this
thread [8], but essentially we'd like to port most of the Perl-native TCK tests
to Python, as more people are familiar with the language, making maintenance of
them easier as well as making it easier to contribute new tests to the somewhat
ancient test suite. Avocado can definitely help here as it does provide a good
foundation and building stones to achieve both.
Work in progress
================
One of the things that we already know is problematic with the current hybrid
TCK+Avocado setup is that if a test fails, the summary that Avocado produces
doesn't quickly tell us which tests have failed and one has to either scroll
through the GitLab job output or wade through Avocado job logs.
-> this issue is tracked in upstream Avocado and should be addressed soon:
https://github.com/avocado-framework/avocado/issues/5200
Another annoying thing in terms of test failure analysis is that TCK in its
current shape cannot save libvirt debug logs on a per-test basis and so a
massive dump is produced for the whole test run. This is very suboptimal, but
this can only be solved with libvirt admin API which can enable/modify/redirect
logs at runtime, however, the perl bindings are currently missings
-> I'm already working on adding the bindings to libvirt-perl and then we
need to teach TCK to use that feature
Known issues
============
There are already a couple of known test failures which can be seen in the
example pipeline:
1) modular daemons occasionally hang in some test scenarios
(doesn't happen with monolithic)
https://bugzilla.redhat.com/show_bug.cgi?id=2044379
2) QEMU tray status detection when a CD media is changed
-> this one is also intermittent, but no good reproducer data to attach
to an official QEMU BZ has been harnessed so far
[1] https://docs.gitlab.com/runner/executors/custom.html
[2] https://gitlab.com/libvirt/libvirt-tck/
[3] https://avocado-framework.readthedocs.io/
[4] https://gitlab.com/eskultety/libvirt/-/pipelines/457836923
[5] https://gitlab.com/libvirt/libvirt-ci/
[6] https://docs.gitlab.com/runner/executors/
[7] https://gitlab.com/eskultety/libvirt-gitlab-executor
[8] https://listman.redhat.com/archives/libvir-list/2021-June/msg00836.html
Erik Skultety (4):
ci: manifest: Allow RPM builds on CentOS Stream 8
ci: containers: Add CentOS Stream 9 target
ci: manifest: Publish RPMs as artifacts on CentOS Stream and Fedoras
gitlab-ci: Introduce a new test 'integration' pipeline stage
.gitlab-ci-integration.yml | 116 +++++++++++++++++++++++
.gitlab-ci.yml | 17 +++-
ci/containers/centos-stream-9.Dockerfile | 87 +++++++++++++++++
ci/gitlab.yml | 33 ++++++-
ci/manifest.yml | 26 ++++-
5 files changed, 274 insertions(+), 5 deletions(-)
create mode 100644 .gitlab-ci-integration.yml
create mode 100644 ci/containers/centos-stream-9.Dockerfile
--
2.34.1
2 years, 2 months