escorts services
by mahom90637＠nab4.com
The top rated escort sites allow you to contact the girl that suits your needs. That is to say, you will be able to call the prostitutes that you consider to be the most beautiful, sensual, or simply cheap.
https://www.canadaescorts.ca
1 month, 2 weeks
[PATCH v4 0/5] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v4
- added qemu.conf option to dictate the default behavior for the
deprecated_features attribute (Boris)
- added qemuxmlactivetests (Boris)
- snuck in missing documentation for deprecated_features in
formatdomain.rst
v3
- added qemu caps check to avoid breaking s390 guests trying to
default deprecated_features='off' on QEMU versions that
do not support reporting these features
v2
- changed behavior from disabling features on the host model to
instead flagging the guest CPU to disable deprecated features
- removed disabling deprecated features on host model in
virQEMUCapsInitCPUModelS390
- added flagging deprecated_feats in qemuProcessUpdateGuestCPU
- added tests for deprecated_features='on'
- split virQEMUCapsUpdateCPUDeprecatedFeatures update and
qemuProcessUpdateGuestCPU changes
The intention of reporting deprecated features and modifying the guest
CPU model was to alleviate the user from the burden of preparing a guest
with the necessary amendments to assure migration to newer hardware.
While that goal was met by way of the "deprecated_features='on|off'"
attribute, it still adds an extra step that the user must be aware to
prepare a guest for migration and the errors that stem from an
unsuccessful migration (due to feature incompatibility) is not always
clear how to resolve.
These patches make s390 CPU *host models* migration ready from the get-go
by introducing a qemu.conf option for disabling deprecated features by
default. They may still be disabled for other model types via the
respective attribute, or reenabled if desired. The configured behavior
may be overridden by explicitly providing the attribute within the
guest XML.
Boris Fiuczynski (1):
tests: new qemuxmlactive tests for s390x
Collin Walling (4):
docs: domain: document deprecated_features attribute
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
qemu: add default_cpu_deprecated_features configuration option
docs/formatdomain.rst | 8 ++++
src/qemu/libvirtd_qemu.aug | 3 ++
src/qemu/qemu.conf.in | 14 ++++++
src/qemu/qemu_capabilities.c | 6 +--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_conf.c | 33 +++++++++++++
src/qemu/qemu_conf.h | 12 +++++
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 46 +++++++++++++++----
src/qemu/test_libvirtd_qemu.aug.in | 1 +
...ated-features-none-active.s390x-latest.xml | 25 ++++++++++
...ed-features-none-inactive.s390x-latest.xml | 25 ++++++++++
...cated-features-off-active.s390x-latest.xml | 25 ++++++++++
...ted-features-off-inactive.s390x-latest.xml | 25 ++++++++++
...ecated-features-on-active.s390x-latest.xml | 25 ++++++++++
...ated-features-on-inactive.s390x-latest.xml | 25 ++++++++++
tests/qemuxmlactivetest.c | 11 ++++-
...deprecated-features-none.s390x-latest.args | 32 +++++++++++++
...-deprecated-features-none.s390x-latest.xml | 25 ++++++++++
.../cpu-model-deprecated-features-none.xml | 15 ++++++
...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++
...el-deprecated-features-on.s390x-latest.xml | 25 ++++++++++
.../cpu-model-deprecated-features-on.xml | 15 ++++++
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 2 +
30 files changed, 426 insertions(+), 22 deletions(-)
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-active.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-inactive.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-active.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-inactive.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-active.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-inactive.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml
--
2.47.1
1 month, 2 weeks
[PATCH v3 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober
Similar to the qemu.conf file that allows QEMU specific configurations we add
the possibility to specify a ch.conf file for Cloud Hypervisor configuration.
The initial single config option is the log level, which sets the verbosity of
the Cloud Hypervisor process. This allows for simpler debugging when using
Cloud Hypervisor via libvirt.
Stefan Kober (3):
ch: Add config file support
ch: add log level configuration option
NEWS: ch: announce log_level config option
NEWS.rst | 5 +++++
src/ch/ch.conf | 11 ++++++++++
src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++
src/ch/ch_conf.h | 18 +++++++++++++++
src/ch/ch_driver.c | 6 +++++
src/ch/ch_monitor.c | 6 +++++
src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++
src/ch/meson.build | 12 ++++++++++
src/ch/test_libvirtd_ch.aug.in | 5 +++++
9 files changed, 134 insertions(+)
create mode 100644 src/ch/ch.conf
create mode 100644 src/ch/libvirtd_ch.aug
create mode 100644 src/ch/test_libvirtd_ch.aug.in
--
2.49.0
1 month, 2 weeks
[PATCH 0/3] qemu: Replace usb-storage with usb-bot
by Akihiko Odaki
usb-storage is a compound device that automatically creates a USB mass
storage device and a SCSI device as its backend. Unfortunately it lacks
some configuration options that are usually present with a SCSI device,
and cannot represent CD-ROM in particular.
Replace usb-storage with usb-bot, which can be combined with a manually
created SCSI device. libvirt will configure the SCSI device in a way
identical with how QEMU does for usb-storage except that now it respects
a configuration option to represent CD-ROM.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368
Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com>
---
Akihiko Odaki (3):
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT
qemu: Replace usb-storage with usb-bot
qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE
src/qemu/qemu_alias.c | 3 +-
src/qemu/qemu_capabilities.c | 19 +-
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_command.c | 55 +++++-
src/qemu/qemu_command.h | 5 +
src/qemu/qemu_hotplug.c | 34 +++-
src/qemu/qemu_validate.c | 4 +-
.../qemucapabilitiesdata/caps_10.0.0_s390x.replies | 186 ++++---------------
tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 2 +-
.../caps_10.0.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 2 +-
.../caps_5.2.0_aarch64.replies | 174 ++++-------------
tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_5.2.0_ppc64.replies | 178 +++++-------------
tests/qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 2 +-
.../caps_5.2.0_riscv64.replies | 170 ++++-------------
tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +-
.../qemucapabilitiesdata/caps_5.2.0_x86_64.replies | 190 +++++--------------
tests/qemucapabilitiesdata/caps_5.2.0_x86_64.xml | 2 +-
.../caps_6.0.0_aarch64.replies | 172 ++++-------------
tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_6.0.0_x86_64.replies | 188 +++++--------------
tests/qemucapabilitiesdata/caps_6.0.0_x86_64.xml | 2 +-
.../qemucapabilitiesdata/caps_6.1.0_x86_64.replies | 194 +++++--------------
tests/qemucapabilitiesdata/caps_6.1.0_x86_64.xml | 2 +-
.../caps_6.2.0_aarch64.replies | 178 ++++--------------
tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_6.2.0_ppc64.replies | 182 +++++-------------
tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 +-
.../qemucapabilitiesdata/caps_6.2.0_x86_64.replies | 194 +++++--------------
tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 2 +-
.../caps_7.0.0_aarch64+hvf.replies | 182 +++++-------------
.../caps_7.0.0_aarch64+hvf.xml | 2 +-
.../caps_7.0.0_aarch64.replies | 182 +++++-------------
tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_7.0.0_ppc64.replies | 182 +++++-------------
tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 +-
.../qemucapabilitiesdata/caps_7.0.0_x86_64.replies | 194 +++++--------------
tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 2 +-
.../qemucapabilitiesdata/caps_7.1.0_ppc64.replies | 182 +++++-------------
tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 +-
.../qemucapabilitiesdata/caps_7.1.0_x86_64.replies | 194 +++++--------------
tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 2 +-
tests/qemucapabilitiesdata/caps_7.2.0_ppc.replies | 186 ++++---------------
tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 +-
.../caps_7.2.0_x86_64+hvf.replies | 206 +++++----------------
.../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 2 +-
.../qemucapabilitiesdata/caps_7.2.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 2 +-
.../caps_8.0.0_riscv64.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 2 +-
.../qemucapabilitiesdata/caps_8.0.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 2 +-
.../qemucapabilitiesdata/caps_8.1.0_s390x.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 +-
.../qemucapabilitiesdata/caps_8.1.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 2 +-
.../caps_8.2.0_aarch64.replies | 190 ++++---------------
tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_8.2.0_armv7l.replies | 190 ++++---------------
tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 2 +-
.../caps_8.2.0_loongarch64.replies | 186 ++++---------------
.../caps_8.2.0_loongarch64.xml | 2 +-
.../qemucapabilitiesdata/caps_8.2.0_s390x.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 +-
.../qemucapabilitiesdata/caps_8.2.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 2 +-
.../qemucapabilitiesdata/caps_9.0.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 2 +-
.../caps_9.1.0_riscv64.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 2 +-
.../qemucapabilitiesdata/caps_9.1.0_s390x.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 +-
.../qemucapabilitiesdata/caps_9.1.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 2 +-
.../qemucapabilitiesdata/caps_9.2.0_s390x.replies | 182 ++++--------------
tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 +-
.../qemucapabilitiesdata/caps_9.2.0_x86_64.replies | 206 +++++----------------
tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 2 +-
tests/qemuhotplugtest.c | 8 +-
.../qemuxmlconfdata/disk-cache.x86_64-latest.args | 3 +-
.../disk-cdrom-bus-other.x86_64-latest.args | 3 +-
.../disk-device-removable.x86_64-latest.args | 3 +-
.../disk-usb-device.x86_64-latest.args | 3 +-
84 files changed, 1689 insertions(+), 5346 deletions(-)
---
base-commit: e5299ddf86121d3c792ca271ffcb54900eb19dc3
change-id: 20250304-bot-5d84aa3a5cfe
Best regards,
--
Akihiko Odaki <akihiko.odaki(a)daynix.com>
1 month, 2 weeks
[PATCH 0/2] esx: Allow specifying different CA bundle for remote connections
by Martin Kletzander
**El Blurbo aquí**
Martin Kletzander (2):
esx: Allow specifying different CA bundle for remote connections
NEWS: Mention cainfo_path parameter in esx driver
NEWS.rst | 5 +++++
docs/drvesx.rst | 16 ++++++++++++++--
src/esx/esx_util.c | 4 ++++
src/esx/esx_util.h | 1 +
src/esx/esx_vi.c | 3 +++
5 files changed, 27 insertions(+), 2 deletions(-)
--
2.49.0
1 month, 2 weeks
[PATCH] storage: Implement a simple 'checkPool' method for 'rbd' type pools
by Krisstoffe
From: Krisstoffe <krisstoffe(a)free.fr>
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/448
Signed-off-by: Krisstoffe <krisstoffe(a)free.fr>
---
src/storage/storage_backend_rbd.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c
index 038a1a9e34..29d544d349 100644
--- a/src/storage/storage_backend_rbd.c
+++ b/src/storage/storage_backend_rbd.c
@@ -1442,9 +1442,21 @@ virStorageBackendRBDVolWipe(virStoragePoolObj *pool,
}
+static int
+virStorageBackendRBDCheckPool(virStoragePoolObj *pool,
+ bool *active)
+{
+ /* Return previous state remembered by the status XML. If the pool is not
+ * available we will fail to refresh it and end up in the same situation. */
+ *active = virStoragePoolObjIsActive(pool);
+ return 0;
+}
+
+
virStorageBackend virStorageBackendRBD = {
.type = VIR_STORAGE_POOL_RBD,
+ .checkPool = virStorageBackendRBDCheckPool,
.refreshPool = virStorageBackendRBDRefreshPool,
.createVol = virStorageBackendRBDCreateVol,
.buildVol = virStorageBackendRBDBuildVol,
--
2.47.1
1 month, 2 weeks
[RFC PATCH v4 0/4] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe
Hi, all.
This patch adds Arm CCA support to QEMU driver for aarch64 system.
CCA is an abbreviation for Arm Confidential Compute Architecture
feature, it enhances the virtualization capabilities of
the platform by separating the management of resources from access
to those resources.
We are not yet at the stage where we can merge this patch as host
Linux/QEMU support is not yet merged, but I would like to receive
reviews and comments on the overall direction.
Changes in v4:
- Changed the target QEMU binary (Linaro's CCA/v8 version with added
QMP functionality)
- Added the 'armrme' variant to tests/qemucapabilitiesdata/README.rst.
- Renamed data files to include '+armrme':
- tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml
- tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml
- tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies
- tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml
- tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args
- tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml
- Reorganized the commits to ensure the tests pass even with partial
application of the patch.
[summary]
At this stage, all you can do is getting the CCA capability with
the virsh domcapabilities command and start the CCA VM with
the virsh create command.
capability info uses QEMU QMP to query QEMU options. The option
that exists now is for selecting a hash algorithm.
QEMU QMP sections currently only contains a single member, but
is wrapped in sections for expansion.
[Capability example]
Execution results of 'virsh domcapability" on QEMU
<domaincapabilities>
...
<features>
...
</sgx>
<cca supported='yes'>
<enum name='measurement-algo'>
<value>sha256</value>
<value>sha512</value>
</enum>
</cca>
<hyperv supported='yes'>
...
</features>
</domaincapabilities>
[XML example]
<domain>
...
<launchsecurity type='cca'>
<measurement-algo>sha256</measurement-algo>
</launchsecurity>
...
</domain>
[limitations/tests]
To obtain capability info, it is necessary to support the QEMU QMP
command, which QEMU does not yet support. We added a QMP
command to retrieve CCA info for test (See "[software version]"
below). I need to check qemu_firmware.c to see if my CPU firmware
supports CCA. Since it's not implemented yet, I'll wait until a Linux
distributor provides me with a JSON file for CCA.
We have confirmed that the added tests (qemucapabilitiestest,
domaincapstest and qemuxmlconftest) and the CCA VM startup test
(starting the CCA VM from the virsh create command) passed.
The "personalization-value" and "measurement-log" parameters that
exist in the current Linaro QEMU cca/latest branch will not be
specified as CCA VM startup parameters with the virsh create
command.
[software version]
I followed the steps in Linaro's blog below.
https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+...
The QEMU used was enhanced with CCA QMP command and found at:
https://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp
which is based on Linaro QEMU (cca/latest)
https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads
RFC v1:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4...
RFC v2:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5...
RFC v3:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LL...
Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com
Akio Kakuno (3):
src: Add ARM CCA support in qemu driver to launch VM
src: Add ARM CCA support in domain capabilities command
src: Add ARM CCA support in domain schema
Kazuhiro Abe (1):
tests: Adds Arm CCA support
docs/formatdomain.rst | 43 +
docs/formatdomaincaps.rst | 27 +-
src/conf/domain_capabilities.c | 48 +
src/conf/domain_capabilities.h | 12 +
src/conf/domain_conf.c | 25 +
src/conf/domain_conf.h | 9 +
src/conf/domain_validate.c | 1 +
src/conf/schemas/domaincaps.rng | 36 +
src/conf/schemas/domaincommon.rng | 26 +
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 145 +
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_cgroup.c | 2 +
src/qemu/qemu_command.c | 29 +
src/qemu/qemu_driver.c | 2 +
src/qemu/qemu_firmware.c | 1 +
src/qemu/qemu_monitor.c | 10 +
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 98 +
src/qemu/qemu_monitor_json.h | 4 +
src/qemu/qemu_namespace.c | 2 +
src/qemu/qemu_process.c | 4 +
src/qemu/qemu_validate.c | 4 +
src/security/security_dac.c | 2 +
.../qemu_9.2.0-virt.aarch64+armrme.xml | 244 +
.../qemu_9.2.0.aarch64+armrme.xml | 244 +
tests/qemucapabilitiesdata/README.rst | 5 +
.../caps_9.2.0_aarch64+armrme.replies | 36754 ++++++++++++++++
.../caps_9.2.0_aarch64+armrme.xml | 540 +
...ch-security-cca.aarch64-latest+armrme.args | 30 +
...nch-security-cca.aarch64-latest+armrme.xml | 24 +
tests/qemuxmlconfdata/launch-security-cca.xml | 16 +
tests/qemuxmlconftest.c | 2 +
34 files changed, 38398 insertions(+), 1 deletion(-)
create mode 100644 tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml
create mode 100644 tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml
create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies
create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml
--
2.43.5
1 month, 2 weeks
Re: [RFC PATCH v3 4/6] qemucapabilitiestest: Adds Arm CCA support
by Peter Krempa
On Thu, May 29, 2025 at 05:10:48 +0000, Kazuhiro Abe (Fujitsu) wrote:
>
> On 5/20/25 17:54, Peter Krempa wrote:
> > On Tue, May 20, 2025 at 17:28:26 +0900, Kazuhiro Abe wrote:
> > > From: Akio Kakuno <fj3333bs(a)fujitsu.com>
> > >
> > > - This test was added to check qemu capabilities for Arm
> > > CCA support.
> >
> > IF
> >
> > > This test was created using the method described in the
> > > documentation.
> > >
> > > Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com>
> > > ---
> > > .../caps_9.1.0_aarch64.replies | 36222
> > ++++++++++++++++
> > > .../caps_9.1.0_aarch64.xml | 530 +
> > > 2 files changed, 36752 insertions(+)
> > > create mode 100644
> > > tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml
> >
> > Note that I'll be commenting only on the capability testing related matter, not the
> > rest of the series.
> >
> > > diff --git a/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > new file mode 100644
> > > index 0000000000..906a21f0c6
> > > --- /dev/null
> > > +++ b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > @@ -0,0 +1,36222 @@
> > > +{
> > > + "execute": "qmp_capabilities",
> > > + "id": "libvirt-1"
> > > +}
> > > +
> > > +{
> > > + "return": {},
> > > + "id": "libvirt-1"
> > > +}
> > > +
> > > +{
> > > + "execute": "query-version",
> > > + "id": "libvirt-2"
> > > +}
> > > +
> > > +{
> > > + "return": {
> > > + "qemu": {
> > > + "micro": 91,
> > > + "minor": 1,
> > > + "major": 9
> >
> > This is from 9.2.0-rc1. So firstly the file is named wrong, because it was supposed
> > to be 'caps_9.2.0_aarch64.replies' instead.
> >
> > Also except for the currently developed release we require that the .replies files
> > are generated from the final release versions and not the RCs or any other
> > non-final code.
> >
> > The libvirt tree already has qemu caps for 9.2.0 and 10.0.0 for aarch64.
> >
> > What makes these special?
> >
> > If there's a reason to have specific capabilities please add a 'variant'
> > per tests/qemucapabilitiesdata/README.rst
>
> Thanks for your comment.
>
> These were generated from a special QEMU version which support ARM CCA based on 9.2.
> So as a temporary measure, I will add a variant to the replies file,
> and the name will be caps_9.2.0_aarch64+armrme.replies.
I'd expect that now that qemu-10.0 is out you'd be targetting at least
qemu-10.1 [1] as ...
>
> Note that, once the patch about Arm CCA support is merged,
> we will change the replies file name.
... it's not yet merged as you are saying.
[1] We do allow capabilities captured from the currently in development
tree but:
- they must be based on a commit from official qemu git
- you will have to update them to the final version once qemu-N+1
releases.
But since it's not merged yet your patch will need to stay RFC. Please
make sure thoug to note it in the capabilities patch that it's not the
final version yet so that there's no confusion.
Your patch looked like it was something which already exists based on
the commit message and I didn't read the cover letter because I wasn't
too interested in the series itself, I'm just making sure that
capabilities dumps are handled properly so that I don't have to deal
with it later.
1 month, 2 weeks
[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober
This change serves as a proof of concept that adds live migration support to
the Cloud Hypervisor driver. It is meant to show feasibility and to receive
early feedback.
I tested the live migration by invoking:
virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live
Opens:
* What is required for a minimal viable live migration to be merged?
* Job state tracking? (virDomainObjBeginJob, ...)
* What should 'virsh domjobinfo' show?
* Testing?
* Anything else?
Stefan Kober (1):
Initial CH migrate API
src/ch/ch_conf.h | 4 +
src/ch/ch_domain.h | 2 +
src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++-
src/ch/ch_monitor.c | 156 +++++++++++++
src/ch/ch_monitor.h | 8 +
src/ch/ch_process.c | 136 ++++++++++-
src/ch/ch_process.h | 6 +
src/hypervisor/domain_interface.c | 1 +
src/libvirt-domain.c | 15 +-
9 files changed, 680 insertions(+), 10 deletions(-)
--
2.49.0
1 month, 2 weeks
[PATCH] docs: fix list term highlighting in URI docs
by Daniel P. Berrangé
From: Daniel P. Berrangé <berrange(a)redhat.com>
Having a blank line between the term and its definition prevents the RST
to HTML convertor highlighting 'pkipath' correctly.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/uri.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/docs/uri.rst b/docs/uri.rst
index 1d2c68f5b8..cc970001f4 100644
--- a/docs/uri.rst
+++ b/docs/uri.rst
@@ -296,7 +296,6 @@ Supported extra parameters:
**Example:** ``no_verify=1``
``pkipath``
-
Specifies x509 certificates path for the client. If any of the CA
certificate, client certificate, or client key is missing, the connection
will fail with a fatal error.
--
2.49.0
1 month, 2 weeks
