[PATCH 00/10] tests: Introduce tool for qemu '.replies' files
by Peter Krempa
This a much improved version of my first attempt for this tool [1].
This:
- replaces tests/qemucapabilitiesnumbering.c
- including much simpler approach for programatic modification
of the .replies files
- adds 'dump' capability to simplify comparing two qemu versions or
figuring out query strings for qmp schema
[1]: [PATCH] scripts: QMP schema query string helper script
Peter Krempa (10):
tests: qemucaps: Make JSON output identical to python's 'json.dump'
method
syntax-check: Exclude 'scripts/*.py' from
'sc_prohibit_magic_number_exit'
scripts: Add 'qemu-qmp-replies-tool' script for testing and modifying
data for qemucapabilitiestest
tests: Remove 'qemucapabilitiesnumbering' test
util: json: Remove 'virJSONValueObjectReplaceValue'
qemumonitortestutils: Unexport 'qemuMonitorTestProcessFileEntries'
qemu-replies-tool: Add validation of known fields in
'query-qmp-schema'
qemu-replies-tool: Add mode to dump all QMP schema query strings
qemu-replies-tool: Dump 'qom-list-types'
qemu-replies-tool: Dump 'device-list-properties'
build-aux/syntax-check.mk | 3 +
scripts/meson.build | 1 +
scripts/qemu-replies-tool.py | 557 ++++++++++++++++++
src/libvirt_private.syms | 1 -
src/util/virjson.c | 20 -
src/util/virjson.h | 6 -
tests/meson.build | 12 +-
.../caps_4.2.0_aarch64.replies | 42 +-
.../caps_4.2.0_ppc64.replies | 42 +-
.../caps_4.2.0_s390x.replies | 297 ++++------
.../caps_4.2.0_x86_64.replies | 363 ++++--------
.../caps_5.0.0_aarch64.replies | 39 +-
.../caps_5.0.0_ppc64.replies | 39 +-
.../caps_5.0.0_riscv64.replies | 42 +-
.../caps_5.0.0_x86_64.replies | 372 ++++--------
.../caps_5.1.0_sparc.replies | 42 +-
.../caps_5.1.0_x86_64.replies | 291 +++------
.../caps_5.2.0_aarch64.replies | 39 +-
.../caps_5.2.0_ppc64.replies | 39 +-
.../caps_5.2.0_riscv64.replies | 42 +-
.../caps_5.2.0_s390x.replies | 303 ++++------
.../caps_5.2.0_x86_64.replies | 291 +++------
.../caps_6.0.0_aarch64.replies | 39 +-
.../caps_6.0.0_s390x.replies | 303 ++++------
.../caps_6.0.0_x86_64.replies | 291 +++------
.../caps_6.1.0_x86_64.replies | 297 ++++------
.../caps_6.2.0_aarch64.replies | 45 +-
.../caps_6.2.0_ppc64.replies | 45 +-
.../caps_6.2.0_x86_64.replies | 297 ++++------
.../caps_7.0.0_aarch64+hvf.replies | 45 +-
.../caps_7.0.0_aarch64.replies | 45 +-
.../caps_7.0.0_ppc64.replies | 45 +-
.../caps_7.0.0_x86_64.replies | 297 ++++------
.../caps_7.1.0_ppc64.replies | 45 +-
.../caps_7.1.0_x86_64.replies | 297 ++++------
.../caps_7.2.0_ppc.replies | 45 +-
.../caps_7.2.0_x86_64+hvf.replies | 297 ++++------
.../caps_7.2.0_x86_64.replies | 297 ++++------
.../caps_8.0.0_riscv64.replies | 36 +-
.../caps_8.0.0_x86_64.replies | 297 ++++------
.../caps_8.1.0_s390x.replies | 318 ++++------
.../caps_8.1.0_x86_64.replies | 285 +++------
.../caps_8.2.0_aarch64.replies | 48 +-
.../caps_8.2.0_x86_64.replies | 288 +++------
.../caps_9.0.0_x86_64.replies | 288 +++------
tests/qemucapabilitiesnumbering.c | 245 --------
tests/qemucapsprobemock.c | 28 +-
tests/qemumonitortestutils.c | 9 +-
tests/qemumonitortestutils.h | 13 -
49 files changed, 2796 insertions(+), 4672 deletions(-)
create mode 100755 scripts/qemu-replies-tool.py
delete mode 100644 tests/qemucapabilitiesnumbering.c
--
2.43.0
3 months, 2 weeks
[libvirt PATCH] qemu_snapshot: allow reverting to external disk only snapshot
by Pavel Hrdina
When snapshot is created with disk-only flag it is always external
snapshot without memory state. Historically when there was not support
to revert external snapshots this produced error message.
error: Failed to revert snapshot s1
error: internal error: Invalid target domain state 'disk-snapshot'. Refusing snapshot reversion
Now we can simply consider this as reverting to offline snapshot as the
possible damage to file system is already done at the point of snapshot
creation.
Resolves: https://issues.redhat.com/browse/RHEL-21549
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/qemu/qemu_snapshot.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
index 0cac0c4146..7964f70553 100644
--- a/src/qemu/qemu_snapshot.c
+++ b/src/qemu/qemu_snapshot.c
@@ -2606,6 +2606,7 @@ qemuSnapshotRevert(virDomainObj *vm,
case VIR_DOMAIN_SNAPSHOT_SHUTDOWN:
case VIR_DOMAIN_SNAPSHOT_SHUTOFF:
case VIR_DOMAIN_SNAPSHOT_CRASHED:
+ case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT:
ret = qemuSnapshotRevertInactive(vm, snapshot, snap,
driver, cfg,
&inactiveConfig,
@@ -2617,8 +2618,6 @@ qemuSnapshotRevert(virDomainObj *vm,
_("qemu doesn't support reversion of snapshot taken in PMSUSPENDED state"));
goto endjob;
- case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT:
- /* Rejected earlier as an external snapshot */
case VIR_DOMAIN_SNAPSHOT_NOSTATE:
case VIR_DOMAIN_SNAPSHOT_BLOCKED:
case VIR_DOMAIN_SNAPSHOT_LAST:
--
2.43.0
3 months, 2 weeks
[PATCH 0/3] qemu: Improvements related to MODEL_SCSI_AUTO
by Andrea Bolognani
Andrea Bolognani (3):
tests: Add controller-scsi-auto
qemu: Handle MODEL_SCSI_{AUTO,DEFAULT} appropriately
qemu: Use virDomainControllerDefNew() more
src/qemu/qemu_command.c | 4 +--
src/qemu/qemu_domain_address.c | 4 +--
src/qemu/qemu_hotplug.c | 4 +--
src/qemu/qemu_validate.c | 2 +-
.../controller-scsi-auto.x86_64-latest.args | 32 +++++++++++++++++++
.../controller-scsi-auto.x86_64-latest.xml | 30 +++++++++++++++++
.../qemuxmlconfdata/controller-scsi-auto.xml | 15 +++++++++
tests/qemuxmlconftest.c | 1 +
8 files changed, 85 insertions(+), 7 deletions(-)
create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.xml
--
2.43.0
3 months, 2 weeks
Re: Re: [PATCH] apparmor: Add user session path for PID and socket
files used by passt
by Andrea Bolognani
On Tue, Jan 30, 2024 at 10:47:54AM -0800, Andrea Bolognani wrote:
> On Tue, Jan 30, 2024 at 07:15:51PM +0100, Stefano Brivio wrote:
> > Commit 7a39b04d683f ("apparmor: Enable passt support") grants
> > passt(1) read-write access to /{,var/}run/libvirt/qemu/passt/* if
> > started by the libvirt daemon. That's the path where passt creates
> > PID and socket files only if the guest is started by the root user.
> >
> > If the guest is started by another user, though, the path is more
> > commonly /var/run/user/$UID/libvirt/qemu/run/passt: add it as
> > read-write location. Otherwise, passt won't be able to start, as
> > reported by Andreas.
> >
> > While at it, replace /{,var/}run/ in the existing rule by its
> > corresponding tunable variable, @{run}.
> >
> > Reported-by: Andreas B. Mundt <andi(a)debian.org>
> > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061678
> > Fixes: 7a39b04d683f ("apparmor: Enable passt support")
> > Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>
> > ---
> > src/security/apparmor/libvirt-qemu.in | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/security/apparmor/libvirt-qemu.in b/src/security/apparmor/libvirt-qemu.in
> > index f40f471891..8b92915281 100644
> > --- a/src/security/apparmor/libvirt-qemu.in
> > +++ b/src/security/apparmor/libvirt-qemu.in
> > @@ -196,7 +196,8 @@
> > signal (receive) set=("term") peer=libvirtd,
> > signal (receive) set=("term") peer=virtqemud,
> >
> > - owner /{,var/}run/libvirt/qemu/passt/* rw,
> > + owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
> > + owner @{run}/libvirt/qemu/passt/* rw,
>
> Makes sense to me, so
>
> Reviewed-by: Andrea Bolognani <abologna(a)redhat.com>
>
> I'll give Jim and others a chance to take a look before pushing.
I just realized that you sent the patch to the old mailing list
address. We've migrated somewhat recently, so that's completely
understandable :)
I've adjusted the recipient now. I don't think it's necessary for you
to post the patch again, as its contents are fully contained within
the quoted part of this message.
--
Andrea Bolognani / Red Hat / Virtualization
3 months, 2 weeks
[PATCH 00/31] pci vpd: Fix broken XML formatter and refactor questionable error reporting
by Peter Krempa
The first part of the series fixes the XML formatter of nodedevs to not
generate invalid XML if a PCI device custom field contains '>' which
would be printed unescaped
The rest fixes questionable and broken error reporting from the pci vpd
device code which actually parses the above data.
https://gitlab.com/pipo.sk/libvirt/-/pipelines/1157912774
Peter Krempa (31):
virPCIVPDResourceIsValidTextValue: Adjust comment to reflect actual
code
util: pcivpd: Refactor virPCIVPDResourceIsValidTextValue
virNodeDeviceCapVPDFormatCustom*: Escape unsanitized strings
virNodeDeviceCapVPDFormat: Properly escape system-originated strings
schema: nodedev: Adjust allowed characters in 'vpdFieldValueFormat'
tests: Test the previously mishandled PCI VPD characters
Don't overwrite error message from 'virXPathNodeSet'
tests: virpcivpdtest: Remove 'testVirPCIVPDReadVPDBytes' case
util: virpcivpd: Unexport 'virPCIVPDReadVPDBytes'
util: pcivpd: Unexport virPCIVPDParseVPDLargeResourceFields
tests: virpcivpd: Remove 'testVirPCIVPDParseVPDStringResource' case
util: virpcivpd: Unexport 'virPCIVPDParseVPDLargeResourceString'
virPCIVPDResourceGetKeywordPrefix: Fix logging
util: virpcivpd: Remove return value from
virPCIVPDResourceCustomUpsertValue
conf: virNodeDeviceCapVPDParse*: Remove pointless NULL checks
virpcivpdtest: testPCIVPDResourceBasic: Remove tests for uninitialized
'ro'/'rw' section
util: virPCIVPDResourceUpdateKeyword: Remove impossible checks
conf: node_device: Refactor 'virNodeDeviceCapVPDParseCustomFields' to
fix error reporting
virNodeDeviceCapVPDParseXML: Fix error reporting
util: virpcivpd: Remove return value from
virPCIVPDResourceUpdateKeyword
virPCIDeviceHasVPD: Refactor "debug" messages
virPCIDeviceGetVPD: Fix multiple error handling bugs
virPCIDeviceGetVPD: Handle errors in callers
virPCIVPDReadVPDBytes: Refactor error handling
virPCIVPDParseVPDLargeResourceString: Properly report errors
virPCIVPDParseVPDLargeResourceFields: Merge logic conditions
virPCIVPDParseVPDLargeResourceFields: Remove impossible 'default'
swithch case
virPCIVPDParseVPDLargeResourceFields: Refactor processing of read data
virPCIVPDParseVPDLargeResourceFields: Refactor return logic
virPCIVPDParseVPDLargeResourceFields: Report proper errors
virPCIVPDParse: Do reasonable error reporting
src/conf/domain_conf.c | 78 +--
src/conf/network_conf.c | 80 +--
src/conf/node_device_conf.c | 177 +++----
src/conf/numa_conf.c | 15 +-
src/conf/schemas/nodedev.rng | 2 +-
src/cpu/cpu_ppc64.c | 5 +-
src/libvirt_private.syms | 3 -
src/qemu/qemu_capabilities.c | 30 +-
src/qemu/qemu_domain.c | 23 +-
src/qemu/qemu_migration_cookie.c | 5 +-
src/qemu/qemu_nbdkit.c | 5 +-
src/util/virpci.c | 34 +-
src/util/virpcivpd.c | 454 ++++++++----------
src/util/virpcivpd.h | 8 +-
src/util/virpcivpdpriv.h | 11 +-
src/vz/vz_sdk.c | 5 +-
.../pci_0000_42_00_0_vpd.xml | 4 +-
tests/virpcimock.c | 4 +-
tests/virpcitest.c | 3 +-
tests/virpcivpdtest.c | 160 +-----
20 files changed, 386 insertions(+), 720 deletions(-)
--
2.43.0
3 months, 2 weeks
[PATCH v2] meson: Adjust -fstack-protector use
by Andrea Bolognani
Back in 2014, -fstack-protector was reported not to work on
aarch64, so fe881ae086ec disabled it on that target. OS-wise,
its use is currently limited to just Linux, FreeBSD and Windows.
Looking at the situation today, it seems that whatever issue was
affecting aarch64 a decade ago has been resolved; moreover,
macOS can also use the feature these days.
I haven't checked any of the other BSDs, but since the feature
works on FreeBSD it's pretty safe to the assume that they can
use it too. If we get reports that it's not the case, we can
always further restrict its usage accordingly.
Best viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1157984478
Changes from [v1]:
* drop alpha-specific exception.
[v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/R5...
meson.build | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/meson.build b/meson.build
index 611cc582c0..e1c70fce92 100644
--- a/meson.build
+++ b/meson.build
@@ -442,22 +442,17 @@ supported_cc_flags = []
if get_option('warning_level') == '2'
supported_cc_flags = cc.get_supported_arguments(cc_flags)
- # on aarch64 error: -fstack-protector not supported for this target
- if host_machine.cpu_family() != 'aarch64'
- if host_machine.system() in [ 'linux', 'freebsd', 'windows' ]
- # we prefer -fstack-protector-strong but fallback to -fstack-protector-all
- fstack_cflags = cc.first_supported_argument([
- '-fstack-protector-strong',
- '-fstack-protector-all',
- ])
- supported_cc_flags += fstack_cflags
-
- # When building with mingw using -fstack-protector requires libssp library
- # which is included by using -fstack-protector with linker.
- if fstack_cflags.length() == 1 and host_machine.system() == 'windows'
- add_project_link_arguments(fstack_cflags, language: 'c')
- endif
- endif
+ # we prefer -fstack-protector-strong but fallback to -fstack-protector-all
+ fstack_cflags = cc.first_supported_argument([
+ '-fstack-protector-strong',
+ '-fstack-protector-all',
+ ])
+ supported_cc_flags += fstack_cflags
+
+ # When building with mingw using -fstack-protector requires libssp library
+ # which is included by using -fstack-protector with linker.
+ if fstack_cflags.length() == 1 and host_machine.system() == 'windows'
+ add_project_link_arguments(fstack_cflags, language: 'c')
endif
if supported_cc_flags.contains('-Wlogical-op')
--
2.43.0
3 months, 2 weeks
[PATCH] scripts: Make check-symfile.py work on alpha
by Andrea Bolognani
The script expects each of the symbols that it looks for to
be in one of three sections, which in nm(1) are described as
follows:
T - The symbol is in the text (code) section.
B - The symbol is in the BSS data section. This section
typically contains zero-initialized or uninitialized
data, although the exact behavior is system dependent.
D - The symbol is in the initialized data section.
When building on alpha, however, some of the symbols show up
in one of two additional sections, specifically:
S - The symbol is in an uninitialized or zero-initialized
data section for small objects.
G - The symbol is in an initialized data section for small
objects.
In other words, S is the same as B and G is the same as D,
except with some optimization for small objects that for some
reason is applied on alpha but not on other architectures.
I have confirmed that, for all the symbols that the script
complained about being missing on alpha, the section is the
expected one, that is, symbols that are reported as B on x86
are reported as S on alpha, and symbols that are reported as
D on x86 are reported as G on alpha.
Note that, while the B section doesn't seem to be used at all
on alpha, at least in our case, the D section still is.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
scripts/check-symfile.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/check-symfile.py b/scripts/check-symfile.py
index 0f6e780df0..c2ee405118 100755
--- a/scripts/check-symfile.py
+++ b/scripts/check-symfile.py
@@ -61,7 +61,7 @@ for elflib in elflibs:
for line in nm:
line = line.decode("utf-8")
- symmatch = re.search(r'''^\S+\s(?:[TBD])\s(\S+)\s*$''', line)
+ symmatch = re.search(r'''^\S+\s(?:[TBSDG])\s(\S+)\s*$''', line)
if symmatch is None:
continue
--
2.43.0
3 months, 2 weeks
[libvirt PATCH] qemu_snapshot: fix detection if non-leaf snapshot isn't in active chain
by Pavel Hrdina
The condition was completely wrong. As per the comment for function
virDomainMomentIsAncestor() it checks that the first argument is
descendant of the second argument.
Consider the following snapshot tree for VM:
s1
|
+- s2
| |
| +- s3
|
+- s4
|
+- s5 (current)
When deleting s2 with the original code we checked if
virDomainMomentIsAncestor(s2, s5) which would return false basically for
any snapshot as s5 is leaf snapshot so no children.
When deleting s2 with fixed code we check if
virDomainMomentIsAncestor(s5, s2) which still returns false but when
deleting s4 it will correctly return true.
Resolves: https://issues.redhat.com/browse/RHEL-23212
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/qemu/qemu_snapshot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
index 73ff533827..af5f995b0d 100644
--- a/src/qemu/qemu_snapshot.c
+++ b/src/qemu/qemu_snapshot.c
@@ -3815,7 +3815,7 @@ qemuSnapshotDeleteValidate(virDomainObj *vm,
}
if (snap != current && snap->nchildren != 0 &&
- virDomainMomentIsAncestor(snap, current)) {
+ !virDomainMomentIsAncestor(current, snap)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("deletion of non-leaf external snapshot that is not in active chain is not supported"));
return -1;
--
2.43.0
3 months, 2 weeks
[PATCH] ch_driver: fix condition in virCHDomainRemoveInactive()
by Purna Pavan Chandra Aekkaladevi
Rectify the condition to remove a domain only if it is not persistent.
Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi(a)linux.microsoft.com>
---
src/ch/ch_domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ch/ch_domain.c b/src/ch/ch_domain.c
index c0d6c75b1d..2f3fae6758 100644
--- a/src/ch/ch_domain.c
+++ b/src/ch/ch_domain.c
@@ -36,7 +36,7 @@ void
virCHDomainRemoveInactive(virCHDriver *driver,
virDomainObj *vm)
{
- if (vm->persistent) {
+ if (!vm->persistent) {
virDomainObjListRemove(driver->domains, vm);
}
}
--
2.34.1
3 months, 2 weeks
