[PATCH 0/2] qemu_command: Generate -mem-prealloc in one corner case more
by Michal Privoznik
This is a result of mu discussion with Jing:
https://listman.redhat.com/archives/libvir-list/2021-September/msg00407.html
Turns out, the problem has nothing to do with my virtio-mem patches so
I'm sending fix separately.
Michal Prívozník (2):
qemuxml2argvtest: Introduce another numa-topology test
qemu_command: Generate -mem-prealloc in one corner case more
src/qemu/qemu_command.c | 17 ++++-----
.../fd-memory-numa-topology.args | 3 +-
.../fd-memory-numa-topology2.args | 5 +--
.../fd-memory-numa-topology3.args | 7 ++--
...d-memory-numa-topology4.x86_64-latest.args | 34 +++++++++++++++++
.../fd-memory-numa-topology4.xml | 37 +++++++++++++++++++
tests/qemuxml2argvtest.c | 1 +
...fd-memory-numa-topology4.x86_64-latest.xml | 1 +
tests/qemuxml2xmltest.c | 1 +
9 files changed, 88 insertions(+), 18 deletions(-)
create mode 100644 tests/qemuxml2argvdata/fd-memory-numa-topology4.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/fd-memory-numa-topology4.xml
create mode 120000 tests/qemuxml2xmloutdata/fd-memory-numa-topology4.x86_64-latest.xml
--
2.32.0
3 years
[libvirt PATCH 0/2] meson: Detect and reject invalid rst2html5 command
by Andrea Bolognani
Previous attempt at solving this issue:
https://listman.redhat.com/archives/libvir-list/2021-June/msg00097.html
The solution presented here should be way more future-proof, though
there's of course always the risk that the format used to report
version information will change in a way that causes our detection to
trip over...
Andrea Bolognani (2):
meson: Use 'rst2html5' instead of 'rst2html' everywhere
meson: Detect and reject invalid rst2html5 command
docs/go/meson.build | 2 +-
docs/kbase/meson.build | 2 +-
docs/manpages/meson.build | 2 +-
docs/meson.build | 8 ++++----
meson.build | 30 +++++++++++++++++++++++++++++-
5 files changed, 36 insertions(+), 8 deletions(-)
--
2.31.1
3 years
[PATCH v3 0/4] Add qemu support setting qos via ovs on ovs interface
by zhangjl02
---
diff to v2:
- Remove passing "actualType" argument, get it inside funtion
- Format code.
diff to v1:
- Move qemuDomainDefIsOvsport from src/qemu/qemu_domain.c to
src/conf/domain_conf.c
- Call virCommandFree(cmd)free cmd before reusing it.
- Ddd g_autofree to variables.
- Reduce usage of virReportError(), and coupled it with return -1.
- Fix remove port qos error.
- Optimise code structure.
Thanks to Michal Privoznik for helping reviewing these patches and solving
problems. Really sorry to bring extra work to review them. I will continue
to learn and become familiar with submission process.
Now libvirt use tc rules to manage interface's qos. But when an interface
is created by ovs, there is no qos setting result in ovs database. Therefore,
qos of ovs port should be set via ovs management command.
We add a function to tell whether a port definition is an ovs managed virtual
port. Change default qdisc rules, which return 0 directly if the port is ovs
managed(When the ovs port is set noqueue, qos config on this port will not
work). Add ovs management function of setting and cleaning qos. Then check if
the port is an ovs managed port during its life cycle, and call the ovs
management function to set or clean qos settings.
zhangjl02 (4):
virDomain: interface: add virDomainNetDefIsOvsport
virDomain: interface: add virNetDevOpenvswitchInterfaceSetQos and
virNetDevOpenvswitchInterfaceClearQos
qemu: interface: remove setting noqueue for ovs port
qemu: interface: check and use ovs command to set qos of ovs managed
port
src/conf/domain_conf.c | 11 ++
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 3 +
src/qemu/qemu_command.c | 10 +-
src/qemu/qemu_domain.c | 3 +-
src/qemu/qemu_driver.c | 23 ++-
src/qemu/qemu_hotplug.c | 35 ++--
src/qemu/qemu_process.c | 7 +-
src/util/virnetdevopenvswitch.c | 274 ++++++++++++++++++++++++++++++++
src/util/virnetdevopenvswitch.h | 11 ++
10 files changed, 364 insertions(+), 15 deletions(-)
--
2.30.2.windows.1
3 years
[RFC] Allowing SEV attestation
by Michal Prívozník
Dear list,
in the light of recent development of secure virtualization (for instance AMD
SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new
technologies and thus would like to discuss our options. So far, I've came
across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to
adopt its newer version too.
Consider the following example: you loan a VM on a public cloud and you want
to process some private data there. Of course, the data has to be stored on an
encrypted disk/partition. But encrypting guest memory (confidentiality)
prevents you only from finding the key in a memory dump. It doesn't help if
the guest image, initial guest memory, hypervisor or firmware were tampered with.
This is where attestation comes to help - it enables the guest owner (which in
this example is different to the one running it) verify - with cryptographic
level of confidence - that data confidentiality and integrity can be ensured.
Depending on the technology, attestation will be done at different times in
the VM lifecycle. When it's done before starting guest vCPUs, it's called
pre-attestation and when it's done after the guest has launched, it's called
post-attestation. For example, AMD SEV and SEV-ES require pre-attestation.
SEV-SNP allows for post attestation. The crux of the issue here is that *when*
and *how* the guest owner will interact with the VM for attestation will be
different depending on which technology is being used.
It looks like QEMU will expose commands needed for attestation via QMP [3].
But question then is, how to expose those at Libvirt level? Should we allow
users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in
public APIs, or something completely different?
Will those APIs be generic enough to serve other technologies too? For
instance, given set of APIs in given order works for SEV but might not work
for Intel's TDX.
1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-sup...
2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolat...
3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html
Michal
3 years
[libvirt][PATCH v7 0/5] Support query and use SGX
by Haibin Huang
This patch series provides support for enabling Intel's Software Guard Extensions (SGX) feature in guest VM.
Giving the SGX support in QEMU be accepted and will be merged in two days Intel Software Guard Extensions
(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.
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 should contain
<devices>
...
<memory model='sgx-epc'>
<target>
<size unit='KiB'>N</size>
</target>
</memory>
...
</devices>
Haibin Huang (2):
Support to query SGX capability
Add get domaincaps unit test
Lin Yang (3):
conf: Introduce SGX EPC element into device memory xml
qemu: Add command-line to generate SGX EPC memory backend
Add unit tests for guest VM creation command with SGX EPC
docs/schemas/domaincaps.rng | 19 ++-
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_capabilities.c | 29 ++++
src/conf/domain_capabilities.h | 13 ++
src/conf/domain_conf.c | 5 +
src/conf/domain_conf.h | 1 +
src/conf/domain_validate.c | 1 +
src/libvirt_private.syms | 2 +-
src/qemu/qemu_alias.c | 6 +-
src/qemu/qemu_capabilities.c | 142 ++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 39 ++++-
src/qemu/qemu_domain.c | 10 +-
src/qemu/qemu_domain_address.c | 4 +
src/qemu/qemu_monitor.c | 10 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 89 +++++++++++
src/qemu/qemu_monitor_json.h | 3 +
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 +
.../sgx-epc.x86_64-5.1.0.args | 37 +++++
tests/qemuxml2argvdata/sgx-epc.xml | 40 +++++
tests/qemuxml2argvtest.c | 1 +
120 files changed, 560 insertions(+), 8 deletions(-)
create mode 100644 tests/qemuxml2argvdata/sgx-epc.x86_64-5.1.0.args
create mode 100644 tests/qemuxml2argvdata/sgx-epc.xml
--
2.17.1
3 years
[PATCH 0/5] qemu: Prefer -numa cpu over -numa node,cpus=
by Michal Privoznik
I've sent these patches a while ago. Resending them again to resume the
discussion.
https://listman.redhat.com/archives/libvir-list/2020-May/msg01035.html
Michal Prívozník (5):
virCPUDefParseXML: Parse uint using virXPathUInt()
virCPUDefParseXML: Prefer virXMLPropUInt over virXPathUInt
qemuBuildNumaCommandLine: Move vars into loops
qemuBuildNumaCommandLine: Separate out building of CPU list
qemu: Prefer -numa cpu over -numa node,cpus=
src/conf/cpu_conf.c | 45 ++----
src/qemu/qemu_command.c | 151 ++++++++++++++++--
.../hugepages-nvdimm.x86_64-latest.args | 4 +-
...memory-default-hugepage.x86_64-latest.args | 10 +-
.../memfd-memory-numa.x86_64-latest.args | 10 +-
...y-hotplug-nvdimm-access.x86_64-latest.args | 4 +-
...ory-hotplug-nvdimm-align.x86_64-5.2.0.args | 4 +-
...ry-hotplug-nvdimm-align.x86_64-latest.args | 4 +-
...ory-hotplug-nvdimm-label.x86_64-5.2.0.args | 4 +-
...ry-hotplug-nvdimm-label.x86_64-latest.args | 4 +-
...mory-hotplug-nvdimm-pmem.x86_64-5.2.0.args | 4 +-
...ory-hotplug-nvdimm-pmem.x86_64-latest.args | 4 +-
...-hotplug-nvdimm-readonly.x86_64-5.2.0.args | 4 +-
...hotplug-nvdimm-readonly.x86_64-latest.args | 4 +-
.../memory-hotplug-nvdimm.x86_64-latest.args | 4 +-
...mory-hotplug-virtio-pmem.x86_64-5.2.0.args | 4 +-
...ory-hotplug-virtio-pmem.x86_64-latest.args | 4 +-
.../numatune-hmat.x86_64-latest.args | 18 ++-
...emnode-restrictive-mode.x86_64-latest.args | 38 ++++-
.../numatune-memnode.x86_64-5.2.0.args | 38 ++++-
.../numatune-memnode.x86_64-latest.args | 38 ++++-
...vhost-user-fs-fd-memory.x86_64-latest.args | 4 +-
...vhost-user-fs-hugepages.x86_64-latest.args | 4 +-
...host-user-gpu-secondary.x86_64-latest.args | 3 +-
.../vhost-user-vga.x86_64-latest.args | 3 +-
25 files changed, 338 insertions(+), 76 deletions(-)
--
2.32.0
3 years, 1 month
[RFC PATCH 00/10] 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.
Qemu uses eBPF program as RSS driver.
For loading RSS eBPF program, the helper is used.
Path to the helper is provided by Qemu through "query-helper-paths" qmp command.
The helper "qemu-ebpf-rss-helper" is built with Qemu and may differ from build to build.
So it's required that the Qemu should provide a proper helper path.
Libvirt would call the helper and receive the program and map fd through unix socket.
Fds would be passed to Qemu in "ebpf_rss_fds" property by passing to child process or unix socket.
If libvirt would fail at helper call or Qemu didn't provide the path,
the Qemu would be launched without "ebpf_rss_fds" property.
Without "ebpf_rss_fds" property, Qemu would try to load eBPF program by
itself - usually, it would require additional system permissions.
Qemu may use "in-qemu" RSS as a fallback option, which will not require system
permissions, but doesn't work with vhost TAP.
Qemu patches: https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg03535.html
Andrew Melnychenko (10):
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.
virsocket: Added receive for multiple fds.
qemu_capabilities: Added capability for qemu's "ebpf_rss_fds".
qemu_capabilities: Added capability for ebpf helper path.
qemu_interface: Added ebpf helper call.
qemu_command: Added ebpf RSS helper call for NIC creation.
qemu_hotplug: Added helper call for hotplug NIC.
docs: Added descriptions for "rss" and "rss_hash_report"
configurations.
docs/formatdomain.rst | 16 +++++++
src/conf/domain_conf.c | 31 +++++++++++++-
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 48 +++++++++++++++++++++
src/qemu/qemu_capabilities.h | 5 +++
src/qemu/qemu_command.c | 46 +++++++++++++++++++-
src/qemu/qemu_command.h | 2 +
src/qemu/qemu_hotplug.c | 30 ++++++++++++-
src/qemu/qemu_interface.c | 54 +++++++++++++++++++++++
src/qemu/qemu_interface.h | 2 +
src/qemu/qemu_monitor.c | 9 ++++
src/qemu/qemu_monitor.h | 3 ++
src/qemu/qemu_monitor_json.c | 50 ++++++++++++++++++++++
src/qemu/qemu_monitor_json.h | 3 ++
src/qemu/qemu_validate.c | 16 +++++++
src/util/virsocket.c | 83 ++++++++++++++++++++++++++++++++++++
src/util/virsocket.h | 2 +
18 files changed, 399 insertions(+), 4 deletions(-)
--
2.31.1
3 years, 1 month
[PATCH v2] virsh: Add QMP command wrapping for 'qemu-monitor-command'
by Peter Krempa
Issuing simple QMP commands is pain as they need to be wrapped by the
JSON wrapper:
{ "execute": "COMMAND" }
and optionally also:
{ "execute": "COMMAND", "arguments":...}
For simple commands without arguments we can add syntax sugar to virsh
which allows simple usage of QMP and additionally prepares also for
passing through of the 'arguments' section:
virsh qemu-monitor-command $VM query-status
is equivalent to
virsh qemu-monitor-command $VM '{"execute":"query-status"}'
and
virsh qemu-monitor-command $VM query-named-block-nodes '{"flat":true}'
or
virsh qemu-monitor-command $VM query-named-block-nodes '"flat":true'
is equivalent to
virsh qemu-monitor-command $VM '{"execute":"query-named-block-nodes", "arguments":{"flat":true}}'
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
v2:
- dropped the '--qmpwrap' option and do wrapping if we don't get a
JSON object instead. Similarly for arguments.
docs/manpages/virsh.rst | 16 ++++++-
tools/virsh-domain.c | 98 ++++++++++++++++++++++++++++++++++++-----
2 files changed, 103 insertions(+), 11 deletions(-)
diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
index 350ded2026..b4d31bf884 100644
--- a/docs/manpages/virsh.rst
+++ b/docs/manpages/virsh.rst
@@ -7772,7 +7772,21 @@ If more than one argument is provided for *command*, they are concatenated with
a space in between before passing the single command to the monitor.
Note that libvirt uses the QMP to talk to qemu so *command* must be valid JSON
-in QMP format to work properly.
+in QMP format to work properly. If *command* is not a JSON object libvirt tries
+to wrap it as a JSON object to provide convenient interface such as the groups
+of commands with identical handling:
+
+::
+
+ # simple command
+ $ virsh qemu-monitor-command VM commandname
+ $ virsh qemu-monitor-command VM '{"execute":"commandname"}'
+
+ # with arguments
+ $ virsh qemu-monitor-command VM commandname '"arg1":123' '"arg2":"test"'
+ $ virsh qemu-monitor-command VM commandname '{"arg1":123,"arg2":"test"}'
+ $ virsh qemu-monitor-command VM '{"execute":"commandname", "arguments":{"arg1":123,"arg2":"test"}}'
+
If *--pretty* is given the QMP reply is pretty-printed.
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 70aa4167c2..659aa1a242 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -9445,6 +9445,84 @@ static const vshCmdOptDef opts_qemu_monitor_command[] = {
{.name = NULL}
};
+
+static char *
+cmdQemuMonitorCommandConcatCmd(vshControl *ctl,
+ const vshCmd *cmd,
+ const vshCmdOpt *opt)
+{
+ g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
+
+ while ((opt = vshCommandOptArgv(ctl, cmd, opt)))
+ virBufferAsprintf(&buf, "%s ", opt->data);
+
+ virBufferTrim(&buf, " ");
+
+ return virBufferContentAndReset(&buf);
+}
+
+
+static char *
+cmdQemuMonitorCommandQMPWrap(vshControl *ctl,
+ const vshCmd *cmd)
+{
+ g_autofree char *fullcmd = cmdQemuMonitorCommandConcatCmd(ctl, cmd, NULL);
+ g_autoptr(virJSONValue) fullcmdjson = virJSONValueFromString(fullcmd);
+ g_autofree char *fullargs = NULL;
+ g_autoptr(virJSONValue) fullargsjson = NULL;
+ const vshCmdOpt *opt = NULL;
+ const char *commandname = NULL;
+ g_autoptr(virJSONValue) command = NULL;
+ g_autoptr(virJSONValue) arguments = NULL;
+
+ /* if we've got a JSON object, pass it through */
+ if (virJSONValueIsObject(fullcmdjson))
+ return g_steal_pointer(&fullcmd);
+
+ /* we try to wrap the command and possible arguments into a JSON object, if
+ * we as fall back we pass through what we've got from the user */
+
+ if ((opt = vshCommandOptArgv(ctl, cmd, opt)))
+ commandname = opt->data;
+
+ /* now we process arguments similarly to how we've dealt with the full command */
+ if ((fullargs = cmdQemuMonitorCommandConcatCmd(ctl, cmd, opt)))
+ fullargsjson = virJSONValueFromString(fullargs);
+
+ /* for empty args or a valid JSON object we just use that */
+ if (!fullargs || virJSONValueIsObject(fullargsjson)) {
+ arguments = g_steal_pointer(&fullargsjson);
+ } else {
+ /* for a non-object we try to concatenate individual _ARGV bits into a
+ * JSON object wrapper and try using that */
+ g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
+
+ virBufferAddLit(&buf, "{");
+ /* opt points to the _ARGV option bit containing the command so we'll
+ * iterate through the arguments now */
+ while ((opt = vshCommandOptArgv(ctl, cmd, opt)))
+ virBufferAsprintf(&buf, "%s,", opt->data);
+
+ virBufferTrim(&buf, ",");
+ virBufferAddLit(&buf, "}");
+
+ if (!(arguments = virJSONValueFromString(virBufferCurrentContent(&buf)))) {
+ vshError(ctl, _("failed to wrap arguments '%s' into a QMP command wrapper"),
+ fullargs);
+ return NULL;
+ }
+ }
+
+ if (virJSONValueObjectCreate(&command,
+ "s:execute", commandname,
+ "A:arguments", &arguments,
+ NULL) < 0)
+ return NULL;
+
+ return virJSONValueToString(command, false);
+}
+
+
static bool
cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd)
{
@@ -9453,8 +9531,6 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd)
g_autofree char *result = NULL;
g_autoptr(virJSONValue) resultjson = NULL;
unsigned int flags = 0;
- const vshCmdOpt *opt = NULL;
- g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
bool pretty = vshCommandOptBool(cmd, "pretty");
bool returnval = vshCommandOptBool(cmd, "return-value");
virJSONValue *formatjson;
@@ -9466,15 +9542,17 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd)
if (!(dom = virshCommandOptDomain(ctl, cmd, NULL)))
return false;
- while ((opt = vshCommandOptArgv(ctl, cmd, opt)))
- virBufferAsprintf(&buf, "%s ", opt->data);
-
- virBufferTrim(&buf, " ");
-
- monitor_cmd = virBufferContentAndReset(&buf);
-
- if (vshCommandOptBool(cmd, "hmp"))
+ if (vshCommandOptBool(cmd, "hmp")) {
flags |= VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP;
+ monitor_cmd = cmdQemuMonitorCommandConcatCmd(ctl, cmd, NULL);
+ } else {
+ monitor_cmd = cmdQemuMonitorCommandQMPWrap(ctl, cmd);
+ }
+
+ if (!monitor_cmd) {
+ vshSaveLibvirtError();
+ return NULL;
+ }
if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, flags) < 0)
return false;
--
2.31.1
3 years, 1 month
[libvirt PATCH 0/7] Accumulated mdev fixes
by Jonathon Jongsma
These patches fix a couple of outstanding issues with mdev support. These include:
1. output proper xml for the mdev parent device when run under the test suite
2. mdevctl allows multiple devices with the same UUID (but different parents),
so we have to be prepared to handle this. This also requires a change in
nodedev name for mdev devices. From 'mdev_$UUID' to 'mdev_$UUID_$PARENTADDR'
3. validate input xml when defining or creating mdevs (e.g. ensure we have a
proper parent device)
This patch obsoletes the previous patch titled "nodedev: Handle inactive mdevs
with the same UUID"
Jonathon Jongsma (7):
nodedev: add internal virNodeDeviceObjListFind()
nodedev: fix xml output for mdev parents in test suite
nodedev: cache parent address in mdev caps
nodedev: Add parser validation for node devices
nodedev: add PostParse callback for nodedev parsing
nodedev: Handle inactive mdevs with the same UUID
nodedev: look up mdevs by UUID and parent
src/conf/node_device_conf.c | 37 +++-
src/conf/node_device_conf.h | 21 +-
src/conf/virnodedeviceobj.c | 71 +++++--
src/conf/virnodedeviceobj.h | 15 +-
src/hypervisor/domain_driver.c | 7 +-
src/libvirt_private.syms | 1 +
src/node_device/node_device_driver.c | 182 ++++++++++++++----
src/node_device/node_device_driver.h | 6 +
src/node_device/node_device_udev.c | 21 +-
src/test/test_driver.c | 6 +-
.../mdevctl-list-multiple.out.xml | 16 +-
tests/nodedevmdevctltest.c | 36 +++-
tests/nodedevxml2xmltest.c | 3 +-
13 files changed, 338 insertions(+), 84 deletions(-)
--
2.31.1
3 years, 1 month
[PATCH 0/3] Implement paeg-per-vq to virtio devices
by Han Han
The the paeg-per-vq option controlles the VQ Notification Virtio Capability,
added since QEMU 2.8(commit d9997d89a4). It could bring some flexibility[1][2]
to vhost_vdpa.
Gavi, I am not very clear about how it can help with vhost_vdpa. So I
paste some description from the doc of your previous patch[3]. And feel
free to rely with your "Signed-off-by: " :)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1925363
Reference:
[1]: https://doc.dpdk.org/guides/sample_app_ug/vdpa.html
[2]: https://lkml.org/lkml/2020/6/1/1688
[3]:
https://listman.redhat.com/archives/libvir-list/2021-May/msg00143.html
Han Han (3):
qemu_capabilities: Add flag QEMU_CAPS_VIRTIO_PAGE_PER_VQ
conf: Add page_per_vq for driver element
qemu: Add support for virtio device option paeg-per-vq
docs/formatdomain.rst | 9 +++++
docs/schemas/domaincommon.rng | 5 +++
src/conf/domain_conf.c | 16 ++++++++
src/conf/domain_conf.h | 1 +
src/conf/domain_validate.c | 7 ++++
src/qemu/qemu_capabilities.c | 6 +++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 4 ++
src/qemu/qemu_hotplug.c | 3 +-
src/qemu/qemu_validate.c | 8 ++++
.../caps_2.11.0.s390x.xml | 1 +
.../caps_2.11.0.x86_64.xml | 1 +
.../caps_2.12.0.aarch64.xml | 1 +
.../caps_2.12.0.ppc64.xml | 1 +
.../caps_2.12.0.s390x.xml | 1 +
.../caps_2.12.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 +
.../caps_3.0.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 +
.../caps_3.1.0.x86_64.xml | 1 +
.../caps_4.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 +
.../caps_4.0.0.riscv32.xml | 1 +
.../caps_4.0.0.riscv64.xml | 1 +
.../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 +
.../caps_4.0.0.x86_64.xml | 1 +
.../caps_4.1.0.x86_64.xml | 1 +
.../caps_4.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 +
.../caps_4.2.0.x86_64.xml | 1 +
.../caps_5.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
.../caps_5.0.0.riscv64.xml | 1 +
.../caps_5.0.0.x86_64.xml | 1 +
.../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 +
.../virtio-options-controller-page_per_vq.err | 1 +
...-controller-page_per_vq.x86_64-latest.args | 37 ++++++++++++++++++
.../virtio-options-controller-page_per_vq.xml | 38 ++++++++++++++++++
.../virtio-options-disk-page_per_vq.err | 1 +
...ptions-disk-page_per_vq.x86_64-latest.args | 39 +++++++++++++++++++
.../virtio-options-disk-page_per_vq.xml | 34 ++++++++++++++++
.../virtio-options-fs-page_per_vq.err | 1 +
...-options-fs-page_per_vq.x86_64-latest.args | 37 ++++++++++++++++++
.../virtio-options-fs-page_per_vq.xml | 34 ++++++++++++++++
.../virtio-options-input-page_per_vq.err | 1 +
...tions-input-page_per_vq.x86_64-latest.args | 35 +++++++++++++++++
.../virtio-options-input-page_per_vq.xml | 30 ++++++++++++++
.../virtio-options-memballoon-page_per_vq.err | 1 +
...-memballoon-page_per_vq.x86_64-latest.args | 33 ++++++++++++++++
.../virtio-options-memballoon-page_per_vq.xml | 23 +++++++++++
.../virtio-options-net-page_per_vq.err | 1 +
...options-net-page_per_vq.x86_64-latest.args | 37 ++++++++++++++++++
.../virtio-options-net-page_per_vq.xml | 34 ++++++++++++++++
.../virtio-options-rng-page_per_vq.err | 1 +
...options-rng-page_per_vq.x86_64-latest.args | 37 ++++++++++++++++++
.../virtio-options-rng-page_per_vq.xml | 32 +++++++++++++++
.../virtio-options-video-page_per_vq.err | 1 +
...tions-video-page_per_vq.x86_64-latest.args | 37 ++++++++++++++++++
.../virtio-options-video-page_per_vq.xml | 36 +++++++++++++++++
.../virtio-options.x86_64-latest.args | 26 ++++++-------
tests/qemuxml2argvdata/virtio-options.xml | 26 ++++++-------
tests/qemuxml2argvtest.c | 22 +++++++++++
73 files changed, 704 insertions(+), 27 deletions(-)
create mode 100644 tests/qemuxml2argvdata/virtio-options-controller-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-controller-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-controller-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-disk-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-disk-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-disk-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-fs-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-fs-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-fs-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-input-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-input-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-input-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-memballoon-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-memballoon-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-memballoon-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-net-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-net-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-net-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-rng-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-rng-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-rng-page_per_vq.xml
create mode 100644 tests/qemuxml2argvdata/virtio-options-video-page_per_vq.err
create mode 100644 tests/qemuxml2argvdata/virtio-options-video-page_per_vq.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/virtio-options-video-page_per_vq.xml
--
2.31.1
3 years, 1 month
