[PATCH v2 0/2] derpecate some block-job- APIs
by Vladimir Sementsov-Ogievskiy
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
2 months
[PATCH] qemu: rdp: Fix 'qemuRdpAvailable()'
by Peter Krempa
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
2 months
Re: [PATCH v8 55/55] docs: Add TDX documentation
by Daniel P. Berrangé
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 :|
2 months
[PATCH v3 00/20] Add qemu RDP server support
by marcandre.lureau＠redhat.com
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
2 months
[PATCH 0/3] cpu_map: Install Ampere-1 ARM CPU models
by Jiri Denemark
BTW, the added test will not actually detect similar issues in the
future (I'm thinking about such test, though), but it will help with
other issues with the ARM CPU map as it hasn't been covered at all.
Jiri Denemark (3):
tests: Add a basic CPU test for aarch64
cpu_map: Install Ampere-1 ARM CPU models
NEWS: Document ARM CPU map bug fix
NEWS.rst | 6 +++++
src/cpu_map/meson.build | 2 ++
tests/cputest.c | 35 +++++++++++++++++++++++++++++
tests/cputestdata/aarch64-guest.xml | 4 ++++
4 files changed, 47 insertions(+)
create mode 100644 tests/cputestdata/aarch64-guest.xml
--
2.49.0
2 months, 1 week
[PATCH v1 00/18] LIBVIRT: X86: TDX support
by Zhenzhong Duan
Hi,
This series brings libvirt the x86 TDX support.
* What's TDX?
TDX stands for Trust Domain Extensions which isolates VMs from
the virtual-machine manager (VMM)/hypervisor and any other software on
the platform.
This patchset extends libvirt to support TDX, with which one can start a TDX
guest from high level rather than running qemu directly.
* Misc
As QEMU use a software emulated way to reset guest which isn't supported by TDX
guest for security reason. We simulate reboot for TDX guest by kill and create a
new one in FakeReboot framework.
Complete code can be found at [1], matching qemu code can be found at [2].
There is a 'QGS' element for attestation which isn't in matching qemu[2] yet.
I keep them intentionally as they will be implemented in qemu as extention
series of [2].
* Test
start/stop/reboot/reset with virsh
stop/reboot trigger in guest
stop with on_poweroff=destroy/restart
reboot with on_reboot=destroy/restart
* Patch organization
- patch 1-4: Support query of TDX capabilities
- patch 5-11: Add TDX type to launchsecurity framework
- patch 12-17: Add reboot/reset support to TDX guest
- patch 18: Add docs
TODO:
- add reconnect logic in virsh command
[1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v1
[2] https://github.com/intel-staging/qemu-tdx/tree/tdx-qemu-upstream-v8
Thanks
Zhenzhong
Changelog:
v1:
- s/virQEMUCapsKVMSupportsSecureGuestINTEL/virQEMUCapsKVMSupportsSecureGuestTDX (Daniel)
- make policy element optional and expose to QEMU directly (Daniel)
- s/qemuProcessSecFakeReboot/qemuProcessFakeRebootViaRecreate (Daniel)
- simplify QGS element schema by supporting only UNIX socket (Daniel)
- add new events VIR_DOMAIN_EVENT_[STOPPED|STARTED] for control plane (Daniel)
- s/quoteGenerationService/quoteGenerationSocket as QEMU
- add virsh reset support
rfcv4:
- add a check to tools/virt-host-validate-qemu.c (Daniel)
- remove check of q35 (Daniel)
- model 'SocktetAddress' QAPI in xml schema (Daniel)
- s/Quote-Generation-Service/quoteGenerationService/ (Daniel)
- define bits in tdx->policy and add validating logic (Daniel)
- presume QEMU choose split kernel irqchip for TDX guest by default (Daniel)
- utilize existing FakeReboot framework to do reboot for TDX guest (Daniel)
- drop patch11 'conf: Add support to keep same domid for hard reboot' (Daniel)
- add test in tests/ to validate parsing and formatting logic (Daniel)
- add doc in docs/formatdomain.rst (Daniel)
- add R-B
rfcv3:
- Change to generate qemu cmdline with -bios
- drop firmware auto match as -bios is used
- add a hard reboot method to reboot TDX guest
rfcv3: https://www.mail-archive.com/devel@lists.libvirt.org/msg00385.html
rfcv2:
- give up using qmp cmd and check TDX directly on host for TDX capabilities.
- use launchsecurity framework to support TDX
- use <os>.<loader> for general loader
- add auto firmware match feature for TDX
A example TDVF fimware description file 70-edk2-x86_64-tdx.json:
{
"description": "UEFI firmware for x86_64, supporting Intel TDX",
"interface-types": [
"uefi"
],
"mapping": {
"device": "generic",
"filename": "/usr/share/OVMF/OVMF_CODE-tdx.fd"
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"intel-tdx",
"verbose-dynamic"
],
"tags": [
]
}
rfcv2: https://www.mail-archive.com/libvir-list@redhat.com/msg219378.html
Zhenzhong Duan (18):
tools: Secure guest check for Intel in virt-host-validate
qemu: Check if INTEL Trust Domain Extention support is enabled
qemu: Add TDX capability
conf: Expose TDX feature in domain capabilities
conf: Add tdx as launch security type
conf: Validate TDX launchSecurity element
mrConfigId/mrOwner/mrOwnerConfig
qemu: Add command line and validation for TDX type
conf: Expose TDX type in domain launch security capability
qemu: Force special parameters enabled for TDX guest
conf: Add Intel TDX Quote Generation Service(QGS) support
qemu: Add command line for TDX Quote Generation Service(QGS)
qemu: Add FakeReboot support for TDX guest
qemu: Support reboot command in guest
qemu: Avoid duplicate FakeReboot for secure guest
qemu: Send event VIR_DOMAIN_EVENT_[STOPPED|STARTED] during recreation
qemu: Bypass sending VIR_DOMAIN_EVENT_RESUMED event when TD VM reboot
qemu: Support domain reset command for TDX guest
docs: domain: Add documentation for Intel TDX guest
docs/formatdomain.rst | 63 ++++++++++++++++++
docs/formatdomaincaps.rst | 1 +
examples/c/misc/event-test.c | 6 ++
include/libvirt/libvirt-domain.h | 2 +
src/conf/domain_capabilities.c | 1 +
src/conf/domain_capabilities.h | 1 +
src/conf/domain_conf.c | 82 +++++++++++++++++++++++
src/conf/domain_conf.h | 21 ++++++
src/conf/domain_validate.c | 11 ++++
src/conf/schemas/domaincaps.rng | 9 +++
src/conf/schemas/domaincommon.rng | 41 ++++++++++++
src/conf/virconftypes.h | 2 +
src/qemu/qemu_capabilities.c | 38 ++++++++++-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_cgroup.c | 1 +
src/qemu/qemu_command.c | 54 +++++++++++++++
src/qemu/qemu_driver.c | 7 ++
src/qemu/qemu_firmware.c | 1 +
src/qemu/qemu_monitor.c | 28 +++++++-
src/qemu/qemu_monitor.h | 2 +-
src/qemu/qemu_monitor_json.c | 6 +-
src/qemu/qemu_namespace.c | 1 +
src/qemu/qemu_process.c | 105 ++++++++++++++++++++++++++++--
src/qemu/qemu_process.h | 2 +
src/qemu/qemu_validate.c | 45 +++++++++++++
src/security/security_dac.c | 2 +
tools/virsh-domain-event.c | 6 +-
tools/virt-host-validate-common.c | 31 ++++++++-
tools/virt-host-validate-common.h | 1 +
29 files changed, 558 insertions(+), 13 deletions(-)
--
2.34.1
2 months, 1 week
[PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs
by Vladimir Sementsov-Ogievskiy
For change, pause, resume, complete, dismiss and finalize actions
corresponding job- and block-job commands are almost equal. The
difference is in find_block_job_locked() vs find_job_locked()
functions. What's different?
1. find_block_job_locked() do check, is found job a block-job. This OK
when moving to more generic API, no needs to document this change.
2. find_block_job_locked() reports DeviceNotActive on failure, when
find_job_locked() reports GenericError. So, lets document this
difference in deprecated.txt. Still, for dismiss and finalize errors
are not documented at all, so be silent in deprecated.txt as well.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru>
---
Hi all!
That's a continuation of my "[RFC 00/15] block job API"[1], exactly, the
simplest part of it - deprecating block-job-* commands which simply
duplicate job-* ones.
Note that the old series was started with trying to introduce job-change
command as substitution to both block-job-change (which only can change
mirror copy-mode parameter), and block-job-set-speed. It was rather
complicated and controversial attempt, which latest implemenation was
"[PATCH v3 0/7] introduce job-change qmp command"[2].
In [2] Kevin noted, that we'd better follow existing blockdev-reopen
approach of changing options (i.e. specify all options) than introduce a
new one. But, on the other hand, now I'm afraid, that rewriting in
third tools simple call to (old good) block-job-set-speed into
job-change(_all_options_ + changed speed) is too much work just for
"having nice interface". And too much for the only two options we want
to change.
So, let's just start from something more obvious. Finally,
we can simple keep block-job-set-speed and block-job-change as is,
as they (unlike other block-job-* commands) are not duplicated by
similar job-* commands.
[1] https://patchew.org/QEMU/20240313150907.623462-1-vsementsov@yandex-team.ru/
[2] https://patchew.org/QEMU/20241002140616.561652-1-vsementsov@yandex-team.ru/
docs/about/deprecated.rst | 31 +++++++++++++++++++++++++++++++
qapi/block-core.json | 30 ++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index e2b4f077d4..eed3356359 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -148,6 +148,37 @@ options are removed in favor of using explicit ``blockdev-create`` and
``blockdev-add`` calls. See :doc:`/interop/live-block-operations` for
details.
+``block-job-pause`` (since 10.1)
+'''''''''''''''''''''''''''''''
+
+Use ``job-pause`` instead. The only difference is that ``job-pause``
+always reports GenericError on failure when ``block-job-pause`` reports
+DeviceNotActive when block-job is not found.
+
+``block-job-resume`` (since 10.1)
+''''''''''''''''''''''''''''''''
+
+Use ``job-resume`` instead. The only difference is that ``job-resume``
+always reports GenericError on failure when ``block-job-resume`` reports
+DeviceNotActive when block-job is not found.
+
+``block-job-complete`` (since 10.1)
+''''''''''''''''''''''''''''''''''
+
+Use ``job-complete`` instead. The only difference is that ``job-complete``
+always reports GenericError on failure when ``block-job-complete`` reports
+DeviceNotActive when block-job is not found.
+
+``block-job-dismiss`` (since 10.1)
+'''''''''''''''''''''''''''''''''
+
+Use ``job-dismiss`` instead.
+
+``block-job-finalize`` (since 10.1)
+''''''''''''''''''''''''''''''''''
+
+Use ``job-finalize`` instead.
+
``query-migrationthreads`` (since 9.2)
''''''''''''''''''''''''''''''''''''''
diff --git a/qapi/block-core.json b/qapi/block-core.json
index b1937780e1..264be8413b 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2968,6 +2968,11 @@
# the name of the parameter), but since QEMU 2.7 it can have other
# values.
#
+# Features:
+#
+# @deprecated: This command is deprecated. Use @job-pause
+# instead.
+#
# Errors:
# - If no background operation is active on this device,
# DeviceNotActive
@@ -2975,6 +2980,7 @@
# Since: 1.3
##
{ 'command': 'block-job-pause', 'data': { 'device': 'str' },
+ 'features': ['deprecated'],
'allow-preconfig': true }
##
@@ -2992,6 +2998,11 @@
# the name of the parameter), but since QEMU 2.7 it can have other
# values.
#
+# Features:
+#
+# @deprecated: This command is deprecated. Use @job-resume
+# instead.
+#
# Errors:
# - If no background operation is active on this device,
# DeviceNotActive
@@ -2999,6 +3010,7 @@
# Since: 1.3
##
{ 'command': 'block-job-resume', 'data': { 'device': 'str' },
+ 'features': ['deprecated'],
'allow-preconfig': true }
##
@@ -3023,6 +3035,11 @@
# the name of the parameter), but since QEMU 2.7 it can have other
# values.
#
+# Features:
+#
+# @deprecated: This command is deprecated. Use @job-complete
+# instead.
+#
# Errors:
# - If no background operation is active on this device,
# DeviceNotActive
@@ -3030,6 +3047,7 @@
# Since: 1.3
##
{ 'command': 'block-job-complete', 'data': { 'device': 'str' },
+ 'features': ['deprecated'],
'allow-preconfig': true }
##
@@ -3047,9 +3065,15 @@
#
# @id: The job identifier.
#
+# Features:
+#
+# @deprecated: This command is deprecated. Use @job-dismiss
+# instead.
+#
# Since: 2.12
##
{ 'command': 'block-job-dismiss', 'data': { 'id': 'str' },
+ 'features': ['deprecated'],
'allow-preconfig': true }
##
@@ -3064,9 +3088,15 @@
#
# @id: The job identifier.
#
+# Features:
+#
+# @deprecated: This command is deprecated. Use @job-finalize
+# instead.
+#
# Since: 2.12
##
{ 'command': 'block-job-finalize', 'data': { 'id': 'str' },
+ 'features': ['deprecated'],
'allow-preconfig': true }
##
--
2.48.1
2 months, 1 week
[PATCH 0/8] Decrease stack size below 2048 bytes
by Michal Privoznik
Inspired by Roman's patch:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/FN...
There are two functions where clang produces stack greater than 2048
bytes (our current limit - see @stack_frame_size in meson.build):
1) doRemoteOpen()
2) vboxSnapshotRedefine()
It took me a while to realize why a function with a dozen variables
requires ~2300 bytes of stack, until the usual suspect turned in - glib.
Anyway, green pipeline:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1752604895
and I've verified this compiles cleanly on my FreeBSD-14.1-RELEASE-p4
VM.
Michal Prívozník (8):
remote_driver: Move URI arg extraction into a separate function
doRemoteOpen: Move RPC talk to a separate function
doRemoteOpen: Drop needless typecast of @transport
vbox: Move parts of vboxSnapshotRedefine() into a separate function
vbox: Move parts of vboxSnapshotRedefine() into a separate function
vbox: Move parts of vboxSnapshotRedefine() into a separate function
vbox: Move parts of vboxSnapshotRedefine() into a separate function
meson: Drop workaround for -Wframe-larger-than and clang
meson.build | 5 -
src/remote/remote_driver.c | 182 ++++---
src/vbox/vbox_common.c | 946 ++++++++++++++++++++-----------------
3 files changed, 636 insertions(+), 497 deletions(-)
--
2.49.0
2 months, 1 week
[PATCH] build: clang stack frame size handling improvement
by Roman Bogorodskiy
The 'plain' optimization type also triggers the clang stack frame size
issues, so increase limit for it as well.
Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com>
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 56823ca25b..0a402a19a2 100644
--- a/meson.build
+++ b/meson.build
@@ -259,7 +259,7 @@ alloc_max = run_command(
stack_frame_size = 2048
# clang without optimization enlarges stack frames in certain corner cases
-if cc.get_id() == 'clang' and get_option('optimization') == '0'
+if cc.get_id() == 'clang' and get_option('optimization') in ['plain', '0']
stack_frame_size = 4096
endif
--
2.49.0
2 months, 1 week
