- Devel - libvirt List Archives

[PATCH] bhyve: support interface type 'network'
by Roman Bogorodskiy 09 Apr '25

09 Apr '25

Add support for interface type 'network'. While bridge remains the only supported options for networks in bhyve, supporting interface type 'network' allows easier configuration and makes domain XMLs more compatible with the other drivers. While here, update the error message for the unsupported interface type to print the requested network type string instead of an integer to make it more user-friendly. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_command.c | 44 ++++++++++++++++++++++++++++++++++----- src/bhyve/bhyve_process.c | 30 +++++++++++++++++++------- 2 files changed, 62 insertions(+), 12 deletions(-) diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index bc287307c8..123d81699f 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -2,6 +2,7 @@ * bhyve_command.c: bhyve command generation * * Copyright (C) 2014 Roman Bogorodskiy + * Copyright (C) 2025 The FreeBSD Foundation * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -26,6 +27,7 @@ #include "bhyve_domain.h" #include "bhyve_conf.h" #include "bhyve_driver.h" +#include "domain_validate.h" #include "datatypes.h" #include "viralloc.h" #include "virfile.h" @@ -40,7 +42,7 @@ VIR_LOG_INIT("bhyve.bhyve_command"); static int -bhyveBuildNetArgStr(const virDomainDef *def, +bhyveBuildNetArgStr(virDomainDef *def, virDomainNetDef *net, struct _bhyveConn *driver, virCommand *cmd, @@ -52,6 +54,7 @@ bhyveBuildNetArgStr(const virDomainDef *def, char *nic_model = NULL; int ret = -1; virDomainNetType actualType = virDomainNetGetActualType(net); + g_autoptr(virConnect) netconn = NULL; if (net->model == VIR_DOMAIN_NET_MODEL_VIRTIO) { nic_model = g_strdup("virtio-net"); @@ -69,12 +72,43 @@ bhyveBuildNetArgStr(const virDomainDef *def, return -1; } - if (actualType == VIR_DOMAIN_NET_TYPE_BRIDGE) { + if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) { + if (!netconn && !(netconn = virGetConnectNetwork())) + goto cleanup; + if (virDomainNetAllocateActualDevice(netconn, def, net) < 0) + goto cleanup; + } + /* final validation now that actual type is known */ + if (virDomainActualNetDefValidate(net) < 0) + return -1; + + switch (actualType) { + case VIR_DOMAIN_NET_TYPE_NETWORK: + case VIR_DOMAIN_NET_TYPE_BRIDGE: brname = g_strdup(virDomainNetGetActualBridgeName(net)); - } else { + if (!brname) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("No bridge name specified")); + goto cleanup; + } + break; + case VIR_DOMAIN_NET_TYPE_ETHERNET: + case VIR_DOMAIN_NET_TYPE_DIRECT: + case VIR_DOMAIN_NET_TYPE_USER: + case VIR_DOMAIN_NET_TYPE_VHOSTUSER: + case VIR_DOMAIN_NET_TYPE_SERVER: + case VIR_DOMAIN_NET_TYPE_CLIENT: + case VIR_DOMAIN_NET_TYPE_MCAST: + case VIR_DOMAIN_NET_TYPE_UDP: + case VIR_DOMAIN_NET_TYPE_INTERNAL: + case VIR_DOMAIN_NET_TYPE_HOSTDEV: + case VIR_DOMAIN_NET_TYPE_VDPA: + case VIR_DOMAIN_NET_TYPE_NULL: + case VIR_DOMAIN_NET_TYPE_VDS: + case VIR_DOMAIN_NET_TYPE_LAST: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Network type %1$d is not supported"), - virDomainNetGetActualType(net)); + _("Unsupported network type %1$s"), + virDomainNetTypeToString(actualType)); goto cleanup; } diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index 3e6f678cf5..a17994e2a0 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -2,6 +2,7 @@ * bhyve_process.c: bhyve process management * * Copyright (C) 2014 Roman Bogorodskiy + * Copyright (C) 2025 The FreeBSD Foundation * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -71,18 +72,23 @@ static void bhyveNetCleanup(virDomainObj *vm) { size_t i; + g_autoptr(virConnect) conn = NULL; for (i = 0; i < vm->def->nnets; i++) { virDomainNetDef *net = vm->def->nets[i]; virDomainNetType actualType = virDomainNetGetActualType(net); - if (actualType == VIR_DOMAIN_NET_TYPE_BRIDGE) { - if (net->ifname) { - ignore_value(virNetDevBridgeRemovePort( - virDomainNetGetActualBridgeName(net), - net->ifname)); - ignore_value(virNetDevTapDelete(net->ifname, NULL)); - } + if (net->ifname) { + ignore_value(virNetDevBridgeRemovePort( + virDomainNetGetActualBridgeName(net), + net->ifname)); + ignore_value(virNetDevTapDelete(net->ifname, NULL)); + } + if (actualType == VIR_DOMAIN_NET_TYPE_NETWORK) { + if (conn || (conn = virGetConnectNetwork())) + virDomainNetReleaseActualDevice(conn, net); + else + VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname)); } } } @@ -437,6 +443,8 @@ virBhyveProcessReconnect(virDomainObj *vm, char **proc_argv; char *expected_proctitle = NULL; bhyveDomainObjPrivate *priv = vm->privateData; + g_autoptr(virConnect) conn = NULL; + size_t i; int ret = -1; if (!virDomainObjIsActive(vm)) @@ -469,6 +477,14 @@ virBhyveProcessReconnect(virDomainObj *vm, } } + for (i = 0; i < vm->def->nnets; i++) { + virDomainNetDef *net = vm->def->nets[i]; + if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK && !conn) + conn = virGetConnectNetwork(); + + virDomainNetNotifyActualDevice(conn, vm->def, net); + } + cleanup: if (ret < 0) { /* If VM is reported to be in active state, but we cannot find -- 2.49.0

2 1

[PATCH 0/3] bhyve: support random number generator device
by Roman Bogorodskiy 09 Apr '25

09 Apr '25

Roman Bogorodskiy (3): bhyve: support random number generator device bhyve: argv2xml: support virtio-rnd devices bhyve: extend RNG device validation src/bhyve/bhyve_capabilities.c | 15 ++++++++ src/bhyve/bhyve_capabilities.h | 2 + src/bhyve/bhyve_command.c | 23 ++++++++++++ src/bhyve/bhyve_device.c | 11 ++++++ src/bhyve/bhyve_domain.c | 21 +++++++++++ src/bhyve/bhyve_parse_command.c | 29 +++++++++++++++ .../bhyveargv2xml-virtio-rnd.args | 8 ++++ .../bhyveargv2xml-virtio-rnd.xml | 20 ++++++++++ tests/bhyveargv2xmltest.c | 1 + ...yvexml2argv-virtio-rnd-backend-builtin.xml | 26 +++++++++++++ ...io-rnd-backend-random-non-default-file.xml | 26 +++++++++++++ .../bhyvexml2argv-virtio-rnd-transitional.xml | 26 +++++++++++++ .../bhyvexml2argv-virtio-rnd.args | 11 ++++++ .../bhyvexml2argv-virtio-rnd.ldargs | 4 ++ .../bhyvexml2argv-virtio-rnd.xml | 26 +++++++++++++ tests/bhyvexml2argvtest.c | 6 +++ .../bhyvexml2xmlout-virtio-rnd.xml | 37 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 18 files changed, 293 insertions(+) create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-rnd.args create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-rnd.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd-backend-builtin.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd-backend-random-non-default-file.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd-transitional.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-rnd.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-virtio-rnd.xml -- 2.49.0

2 4

[PATCH] NEWS: Mention fix for 'qemu-rdp' error being logged
by Peter Krempa 09 Apr '25

09 Apr '25

From: Peter Krempa <pkrempa(a)redhat.com> Add the news entry stating that it's safe to ignore the error. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 2608086717..18b873abe9 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -34,6 +34,16 @@ v11.3.0 (unreleased) installed and thus every attempt to start an ARM domain with custom CPU definition would fail. + * Don't spam logs with with error about ``qemu-rdp`` when starting a qemu VM + + On hosts where the ``qemu-rdp`` binary is not installed a start of a VM + would cause an error such as :: + + error : qemuRdpNewForHelper:103 : 'qemu-rdp' is not a suitable qemu-rdp helper name: No such file or directory + + To be logged in the system log. It is safe to ignore the error. The code + was fixed to avoid the message when probing for support. + v11.2.0 (2025-04-01) ==================== -- 2.49.0

2 1

[PATCH] storage: virStorageVolDefParse and storageVolCreateXML flags fix
by Kirill Shchetiniuk 08 Apr '25

08 Apr '25

When the new storage was created using virsh with --validate option following errors occurred: # virsh vol-create default --file vol-def.xml --validate error: Failed to create vol from vol-def.xml error: unsupported flags (0x4) in function virStorageVolDefParseXML and after virStorageVolDefParse fix: # virsh vol-create default --file vol-def.xml --validate error: Failed to create vol from vol-def.xml error: unsupported flags (0x4) in function storageBackendCreateQemuImg Clear the VIR_STORAGE_VOL_CREATE_VALIDATE flag before virStorageVolDefParseXML and backend->buildVol (traces down to storageBackendCreateQemuImg) calls, as the XML schema validation is already complete within previous steps and there is no validation later. Signed-off-by: Kirill Shchetiniuk <kshcheti(a)redhat.com> --- NEWS.rst | 5 +++++ src/conf/storage_conf.c | 2 ++ src/storage/storage_driver.c | 4 +++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/NEWS.rst b/NEWS.rst index e2dc4e508b..dd345bad7b 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -28,6 +28,11 @@ v11.3.0 (unreleased) * **Bug fixes** + * storage: Fix new volume creation + + No more errors occur when new storage volume is being created + using ``vol-create`` with ``--validate`` option. + v11.2.0 (2025-04-01) ==================== diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 68842004b7..f6d804bb39 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -1409,6 +1409,8 @@ virStorageVolDefParse(virStoragePoolDef *pool, "volume", &ctxt, "storagevol.rng", validate))) return NULL; + flags &= ~(VIR_STORAGE_VOL_CREATE_VALIDATE); + return virStorageVolDefParseXML(pool, ctxt, flags); } diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 86c03762d2..2f5a26bbef 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1877,6 +1877,7 @@ storageVolCreateXML(virStoragePoolPtr pool, virStorageVolPtr vol = NULL, newvol = NULL; g_autoptr(virStorageVolDef) voldef = NULL; unsigned int parseFlags = VIR_VOL_XML_PARSE_OPT_CAPACITY; + unsigned int buildFlags = flags; virCheckFlags(VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA | VIR_STORAGE_VOL_CREATE_VALIDATE, NULL); @@ -1953,8 +1954,8 @@ storageVolCreateXML(virStoragePoolPtr pool, voldef->building = true; virObjectUnlock(obj); - buildret = backend->buildVol(obj, buildvoldef, flags); + buildFlags &= ~(VIR_STORAGE_VOL_CREATE_VALIDATE); + buildret = backend->buildVol(obj, buildvoldef, buildFlags); VIR_FREE(buildvoldef); -- 2.48.1

3 8

[PATCH 0/4] qemu: Remove legacy 'nbd-export-add' code and deprecate corresponding capabilities
by Peter Krempa 08 Apr '25

08 Apr '25

Peter Krempa (4): qemu: block: Always assume support for 'block-export-add' qemu: monitor: Drop wrappers for 'nbd-server-add' qemu: capabilities: Retire QEMU_CAPS_BLOCK_EXPORT_ADD qemu: capabilities: Retire QEMU_CAPS_NBD_BITMAP src/qemu/qemu_block.c | 7 ----- src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 4 +-- src/qemu/qemu_monitor.c | 17 ----------- src/qemu/qemu_monitor.h | 5 ---- src/qemu/qemu_monitor_json.c | 28 ------------------- src/qemu/qemu_monitor_json.h | 6 ---- .../caps_10.0.0_s390x.xml | 2 -- .../caps_10.0.0_x86_64+amdsev.xml | 2 -- .../caps_10.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 -- .../caps_6.2.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 -- .../caps_7.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 -- .../caps_7.1.0_x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 -- .../caps_7.2.0_x86_64+hvf.xml | 2 -- .../caps_7.2.0_x86_64.xml | 2 -- .../caps_8.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 -- .../caps_8.1.0_x86_64.xml | 2 -- .../caps_8.2.0_aarch64.xml | 2 -- .../caps_8.2.0_armv7l.xml | 2 -- .../caps_8.2.0_loongarch64.xml | 2 -- .../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 -- .../caps_8.2.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 2 -- .../caps_9.0.0_x86_64.xml | 2 -- .../caps_9.1.0_riscv64.xml | 2 -- .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 -- .../caps_9.1.0_x86_64.xml | 2 -- .../caps_9.2.0_aarch64+hvf.xml | 2 -- .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 -- .../caps_9.2.0_x86_64+amdsev.xml | 2 -- .../caps_9.2.0_x86_64.xml | 2 -- tests/qemumonitorjsontest.c | 2 -- 37 files changed, 4 insertions(+), 129 deletions(-) -- 2.49.0

2 5

[PATCH] docs: drvqemu: Fix required minimum qemu version to 6.2.0
by Peter Krempa 08 Apr '25

08 Apr '25

From: Peter Krempa <pkrempa(a)redhat.com> Commit 8824af826d3 (and also commit 073bf167843 before it) which bumped minimu, qemu version forgot to update the qemu driver documentation page Fixes: 8824af826d3 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/drvqemu.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drvqemu.rst b/docs/drvqemu.rst index e52d9ffd47..796aae587c 100644 --- a/docs/drvqemu.rst +++ b/docs/drvqemu.rst @@ -5,7 +5,7 @@ QEMU/KVM/HVF hypervisor driver ============================== -The libvirt KVM/QEMU driver can manage any QEMU emulator from version 4.2.0 or +The libvirt KVM/QEMU driver can manage any QEMU emulator from version 6.2.0 or later. It supports multiple QEMU accelerators: software -- 2.49.0

2 1

[PATCH v2 0/2] derpecate some block-job- APIs
by Vladimir Sementsov-Ogievskiy 08 Apr '25

08 Apr '25

v2: Update documentation: add patch 01 v1 was: [PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs Supersedes: <20250401155730.103718-1-vsementsov(a)yandex-team.ru> Vladimir Sementsov-Ogievskiy (2): qapi: synchronize jobs and block-jobs documentation qapi/block-core: derpecate some block-job- APIs docs/about/deprecated.rst | 31 ++++++++++++++ qapi/block-core.json | 89 ++++++++++++++++++++++++++++----------- qapi/job.json | 29 ++++++++++++- 3 files changed, 122 insertions(+), 27 deletions(-) -- 2.48.1

3 7

[PATCH] qemu: rdp: Fix 'qemuRdpAvailable()'
by Peter Krempa 08 Apr '25

08 Apr '25

From: Peter Krempa <pkrempa(a)redhat.com> qemuRdpAvailable() is called from the capability filing code, thus: - it must not report spurious errors - it should not call any extra processes We can solve the above by just checking existance of 'qemu-rdp' in the path as: - at the time of adding of qemuRdpAvailable() there was only one 'qemu-rdp' release - it supported all the features - the check can't change as we'd drop the capability Add comments and gut the check to only check existance of the file. Fixes: f5e5a9bec9ec3e6c762f5000e3b8a0ba6a3a8c8d Closes: https://gitlab.com/libvirt/libvirt/-/issues/763 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_rdp.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_rdp.c b/src/qemu/qemu_rdp.c index 984795d599..0c48b87e7b 100644 --- a/src/qemu/qemu_rdp.c +++ b/src/qemu/qemu_rdp.c @@ -413,12 +413,25 @@ qemuRdpSetCredentials(virDomainObj *vm, } +/** + * qemuRdpAvailable: + * @helper: name (or path to) 'qemu-rdp' binary + * + * Returns whether 'qemu-rdp' is available. + * + * Important: + * This function is called from 'virQEMUDriverGetDomainCapabilities'. It must + * not report any errors and must not add any additional checks. + * + * This function is mocked from 'tests/testutilsqemu.c' + * + */ bool qemuRdpAvailable(const char *helper) { - g_autoptr(qemuRdp) rdp = NULL; - - rdp = qemuRdpNewForHelper(helper); + g_autofree char *helperPath = NULL; - return rdp && qemuRdpHasFeature(rdp, QEMU_RDP_FEATURE_DBUS_ADDRESS); + /* This function was added corresponding to the first release of 'qemu-rdp' + * thus checking existance of the helper binary is sufficient. */ + return !!(helperPath = virFindFileInPath(helper)); } -- 2.49.0

3 2

Re: [PATCH v8 55/55] docs: Add TDX documentation
by Daniel P. Berrangé 08 Apr '25

08 Apr '25

CC libvirt / Jiri, for confirmation about whether the CPUID restrictions listed below will have any possible impact on libvirt CPUID handling... On Tue, Apr 01, 2025 at 09:02:05AM -0400, Xiaoyao Li wrote: > Add docs/system/i386/tdx.rst for TDX support, and add tdx in > confidential-guest-support.rst > > Signed-off-by: Xiaoyao Li <xiaoyao.li(a)intel.com> > --- > Changes in v6: > - Add more information of "Feature configuration" > - Mark TD Attestation as future work because KVM now drops the support > of it. > > Changes in v5: > - Add TD attestation section and update the QEMU parameter; > > Changes since v1: > - Add prerequisite of private gmem; > - update example command to launch TD; > > Changes since RFC v4: > - add the restriction that kernel-irqchip must be split > --- > docs/system/confidential-guest-support.rst | 1 + > docs/system/i386/tdx.rst | 156 +++++++++++++++++++++ > docs/system/target-i386.rst | 1 + > 3 files changed, 158 insertions(+) > create mode 100644 docs/system/i386/tdx.rst > +Feature Configuration > +--------------------- > + > +Unlike non-TDX VM, the CPU features (enumerated by CPU or MSR) of a TD are not > +under full control of VMM. VMM can only configure part of features of a TD on > +``KVM_TDX_INIT_VM`` command of VM scope ``MEMORY_ENCRYPT_OP`` ioctl. > + > +The configurable features have three types: > + > +- Attributes: > + - PKS (bit 30) controls whether Supervisor Protection Keys is exposed to TD, > + which determines related CPUID bit and CR4 bit; > + - PERFMON (bit 63) controls whether PMU is exposed to TD. > + > +- XSAVE related features (XFAM): > + XFAM is a 64b mask, which has the same format as XCR0 or IA32_XSS MSR. It > + determines the set of extended features available for use by the guest TD. > + > +- CPUID features: > + Only some bits of some CPUID leaves are directly configurable by VMM. > + > +What features can be configured is reported via TDX capabilities. > + > +TDX capabilities > +~~~~~~~~~~~~~~~~ > + > +The VM scope ``MEMORY_ENCRYPT_OP`` ioctl provides command ``KVM_TDX_CAPABILITIES`` > +to get the TDX capabilities from KVM. It returns a data structure of > +``struct kvm_tdx_capabilities``, which tells the supported configuration of > +attributes, XFAM and CPUIDs. > + > +TD attributes > +~~~~~~~~~~~~~ > + > +QEMU supports configuring raw 64-bit TD attributes directly via "attributes" > +property of "tdx-guest" object. Note, it's users' responsibility to provide a > +valid value because some bits may not supported by current QEMU or KVM yet. > + > +QEMU also supports the configuration of individual attribute bits that are > +supported by it, via properties of "tdx-guest" object. > +E.g., "sept-ve-disable" (bit 28). > + > +MSR based features > +~~~~~~~~~~~~~~~~~~ > + > +Current KVM doesn't support MSR based feature (e.g., MSR_IA32_ARCH_CAPABILITIES) > +configuration for TDX, and it's a future work to enable it in QEMU when KVM adds > +support of it. > + > +Feature check > +~~~~~~~~~~~~~ > + > +QEMU checks if the final (CPU) features, determined by given cpu model and > +explicit feature adjustment of "+featureA/-featureB", can be supported or not. > +It can produce feature not supported warning like > + > + "warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]" > + > +It can also produce warning like > + > + "warning: TDX forcibly sets the feature: CPUID.80000007H:EDX.invtsc [bit 8]" > + > +if the fixed-1 feature is requested to be disabled explicitly. This is newly > +added to QEMU for TDX because TDX has fixed-1 features that are forcibly enabled > +by TDX module and VMM cannot disable them. This is where I'm wondering if libvirt has anything to be concerned about. Possibly when libvirt queries the actual CPUID after launching the guest it will just "do the right thing" ? Wondering if there's any need for libvirt to be aware of CPUID restrictions before that point though ? > + > +Launching a TD (TDX VM) > +----------------------- > + > +To launch a TD, the necessary command line options are tdx-guest object and > +split kernel-irqchip, as below: > + > +.. parsed-literal:: > + > + |qemu_system_x86| \\ > + -object tdx-guest,id=tdx0 \\ > + -machine ...,kernel-irqchip=split,confidential-guest-support=tdx0 \\ > + -bios OVMF.fd \\ I don't think we need to show 'kernel-irqchip=split' now that we "do the right thing" by default This surely also ought to include '-accel kvm', as IIUC there's no TCG support for TDX. And presumably '-cpu host', since QEMU's default 'qemu64' CPU model is likely a terrible match for what TDX will force set. > + > +Restrictions > +------------ > + > + - kernel-irqchip must be split; Can append "This is set by default for TDX guests if kernel-irqchip is left on its default 'auto' setting." > + > + - No readonly support for private memory; > + > + - No SMM support: SMM support requires manipulating the guest register states > + which is not allowed; > + With 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 :|

3 2

[PATCH v3 00/20] Add qemu RDP server support
by marcandre.lureau＠redhat.com 07 Apr '25

07 Apr '25

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This patch series offers an out-of-process Remote Desktop Protocol (RDP) server solution utilizing QEMU's -display dbus interface, offering improved modularity and potential security benefits compared to built-in server. This initiative was spearheaded by Mihnea Buzatu during the QEMU Summer of Code 2023. The project's goal was to develop an out-of-process RDP server using the -display dbus interface, implemented in Rust. Given that the IronRDP crate lacked some server support at the time, investments in IronRDP were required. I finally released an initial v0.1 version of qemu-rdp on crates.io (https://crates.io/crates/qemu-rdp) That should allow more people to review and evaluate the state of this work. On unix systems, with cargo/rust toolchain installed, it should be as easy as running "cargo install qemu-rdp", apply this patch series for libvirt, set the "rdp_tls_x509_cert_dir" location for your TLS certificates, and configure a VM with both dbus & rdp graphics (run "virsh domdisplay DOMAIN" to get the display connection details). Thanks for the reviews & feedback! v3: thanks to Martin Kletzander review - drop "[PATCH v2 05/21] qemu: fall-through for unsupported graphics" patch - drop extra \n when reporting dbus-daemon log - check password != NULL or VIR_ERR_INTERNAL_ERROR - remove some needless #include/leftover - remove some needless g_auto pointer - rebased - add r-b tags v2: thanks to Daniel review - drop extra error report from "qemu: report an error for unsupported graphics" - replace g_return pre-conditions with ATTRIBUTE_NONNULL - improve "qemu/dbus: keep a connection to the VM D-Bus" to also reconnect - use domainLogContext for logging (for virtiofs as well) - check for qemu-rdp availabilty for setting 'rdp' capability - make dbus-addr qemu-rdp capability mandatory - rebased - add r-b tags Marc-André Lureau (20): build-sys: drop -Winline when optimization=g build: fix -Werror=maybe-uninitialized qemu-slirp: drop unneeded check for OOM util: annotate non-null arguments for virGDBusCallMethod() qemu: add rdp state directory qemu: add qemu RDP configuration conf: parse optional RDP username & password conf: generalize virDomainDefHasSpiceGraphics qemu: use virDomainDefHasGraphics qemu: add RDP ports range allocator qemu: limit to one <graphics type='rdp'> qemu/virtiofs: use domainLogContext qemu/dbus: keep a connection to the VM D-Bus qemu/dbus: log daemon stdout/err, use domainLogContext qemu: validate RDP configuration qemu: add qemu-rdp helper unit qemu: pass virQEMUDriverConfig to capabilities qemu: add 'rdp' capability if qemu-rdp is available qemu: add RDP support tests: add qemu <graphics type='rdp'/> test docs/formatdomain.rst | 25 +- meson.build | 7 +- po/POTFILES | 1 + src/conf/domain_conf.c | 28 +- src/conf/domain_conf.h | 5 +- src/conf/schemas/domaincommon.rng | 10 + src/libvirt_private.syms | 2 +- src/qemu/libvirtd_qemu.aug | 7 + src/qemu/meson.build | 1 + src/qemu/qemu.conf.in | 31 ++ src/qemu/qemu_capabilities.c | 24 +- src/qemu/qemu_capabilities.h | 12 +- src/qemu/qemu_command.c | 8 +- src/qemu/qemu_conf.c | 56 ++- src/qemu/qemu_conf.h | 13 + src/qemu/qemu_dbus.c | 69 ++- src/qemu/qemu_dbus.h | 3 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 4 + src/qemu/qemu_driver.c | 20 + src/qemu/qemu_extdevice.c | 46 +- src/qemu/qemu_hotplug.c | 51 ++- src/qemu/qemu_hotplug.h | 1 + src/qemu/qemu_process.c | 169 ++++++- src/qemu/qemu_rdp.c | 424 ++++++++++++++++++ src/qemu/qemu_rdp.h | 73 +++ src/qemu/qemu_slirp.c | 6 - src/qemu/qemu_validate.c | 48 +- src/qemu/qemu_virtiofs.c | 53 +-- src/qemu/test_libvirtd_qemu.aug.in | 5 + src/util/virgdbus.h | 13 +- .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 1 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 1 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + .../qemu_8.2.0-virt.aarch64.xml | 1 + .../qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 1 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.sparc.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + .../qemu_9.1.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + tests/domaincapstest.c | 7 +- .../graphics-rdp.x86_64-latest.args | 35 ++ .../graphics-rdp.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/graphics-rdp.xml | 43 ++ tests/qemuxmlconftest.c | 2 + tests/testutilsqemu.c | 10 + tools/nss/libvirt_nss_leases.c | 2 +- tools/nss/libvirt_nss_macs.c | 2 +- 92 files changed, 1234 insertions(+), 137 deletions(-) create mode 100644 src/qemu/qemu_rdp.c create mode 100644 src/qemu/qemu_rdp.h create mode 100644 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-rdp.xml -- 2.47.0

5 26