[PATCH V2 0/4] Handle physical address bits
by Jim Fehlig
Hi All,
This is a V2 of Dario's old patches adding support for specifying the
virtual CPU address size in bits
https://listman.redhat.com/archives/libvir-list/2020-October/210901.html
I've rebased those patches to latest master and tweaked them a bit. E.g.
I removed the qemucaps code since phys-bits and host-phys-bits have been
around before the minimum qemu version supported by libvirt. I also added
patches to expose the number of host address bits and ensure ABI stability
as requested in the old review comments.
Dario Faggioli (2):
conf: Add support for specifying CPU max physical address size
qemu: Add support for max physical address size
Jim Fehlig (2):
capabilities: Report number of host CPU physical address bits
cpu conf: Check ABI stability of CPU maxphysaddr config
docs/formatdomain.rst | 23 +++++++
src/conf/cpu_conf.c | 63 +++++++++++++++++++
src/conf/cpu_conf.h | 17 +++++
src/conf/schemas/cputypes.rng | 19 ++++++
src/cpu/cpu_x86.c | 8 +++
src/libvirt_private.syms | 2 +
src/qemu/qemu_command.c | 21 +++++++
src/qemu/qemu_domain.c | 46 ++++++++++++++
src/qemu/qemu_validate.c | 12 ++++
src/util/virhostcpu.c | 55 ++++++++++++++++
src/util/virhostcpu.h | 3 +
.../cpu-phys-bits-emulate.xml | 20 ++++++
.../cpu-phys-bits-passthrough.xml | 20 ++++++
tests/genericxml2xmltest.c | 3 +
.../cpu-phys-bits-emulate.args | 32 ++++++++++
.../cpu-phys-bits-emulate.xml | 20 ++++++
.../cpu-phys-bits-emulate2.args | 32 ++++++++++
.../cpu-phys-bits-emulate2.xml | 20 ++++++
.../cpu-phys-bits-emulate3.err | 1 +
.../cpu-phys-bits-emulate3.xml | 20 ++++++
.../cpu-phys-bits-passthrough.args | 32 ++++++++++
.../cpu-phys-bits-passthrough.xml | 20 ++++++
.../cpu-phys-bits-passthrough2.err | 1 +
.../cpu-phys-bits-passthrough2.xml | 20 ++++++
.../cpu-phys-bits-passthrough3.err | 1 +
.../cpu-phys-bits-passthrough3.xml | 20 ++++++
tests/qemuxml2argvtest.c | 7 +++
27 files changed, 538 insertions(+)
create mode 100644 tests/genericxml2xmlindata/cpu-phys-bits-emulate.xml
create mode 100644 tests/genericxml2xmlindata/cpu-phys-bits-passthrough.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.args
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.args
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.err
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.args
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err
create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml
--
2.36.1
2 years, 8 months
[libvirt PATCH 0/2] fix console device access in ch driver
by Praveen K Paladugu
Patch1:
Drops the check to only have a console/serial device configured
for ch VMs. This is no longer needed.
Patch2:
Addresses https://gitlab.com/libvirt/libvirt/-/issues/344. Libvirt adds compat
console devices for "hvm" VMs. The added console/serial device type is
initialized to VIR_DOMAIN_CHR_TYPE_NULL, when in fact the device added is a pty
device. This patch modifies the default console device type to "pty".
I looked at NOT adding Compat Console devices for ch VMs. But this looked like
a better fix.
Praveen K Paladugu (2):
ch: drop the check to have a single console/serial
conf: set the default chr device type to pty
src/ch/ch_domain.c | 9 +--------
src/conf/domain_conf.c | 1 +
2 files changed, 2 insertions(+), 8 deletions(-)
--
2.27.0
2 years, 8 months
[PATCH 0/3] testutilsqemu: Fake TPM versions
by Michal Privoznik
I thought I've sent these before the freeze but as I tried to ping them,
I realize I didn't. I'm not sure how critical these are to get into the
release (after all we see no test failing), but they make at least
VIR_TEST_DEBUG output of domcapabilities cleaner.
Michal Prívozník (3):
virtpm: Use corresponding type for argument for virTPM*CapsGet()
testutilsqemu: Mock virTPMSwtpmSetupCapsGet()
testutilsqemu: Fake TPM versions
src/util/virtpm.c | 4 ++--
src/util/virtpm.h | 6 +++---
.../domaincapsdata/qemu_3.1.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_3.1.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.0.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_4.0.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 4 ++++
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 4 ++++
.../qemu_5.0.0-virt.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 4 ++++
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 4 ++++
.../qemu_5.2.0-virt.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 4 ++++
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 4 ++++
.../qemu_6.0.0-virt.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 4 ++++
.../qemu_6.2.0-virt.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 4 ++++
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 4 ++++
.../qemu_7.0.0-virt.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 4 ++++
tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 4 ++++
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 4 ++++
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 4 ++++
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 4 ++++
tests/testutilsqemu.c | 19 +++++++++++++++++++
54 files changed, 228 insertions(+), 5 deletions(-)
--
2.35.1
2 years, 8 months
[PATCH 0/8] conf: Don't lose <active_pcr_banks/> when no TPM version is provided
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (8):
conf: Report an error when default TPM model is provided
conf: Report error when default TPM version is provided
conf: Drop needless setting of VIR_DOMAIN_TPM_VERSION_DEFAULT
conf: Move _virDomainTPMDef::version into
_virDomainTPMDef::data::emulator
conf: Use virXMLPropEnum more when parsing TPM
qemu_domain: Move TPM post parse code into qemuDomainTPMDefPostParse()
qemu: Move TPMs validation out of PostParse
conf: Don't lose <active_pcr_banks/> when no TPM version is provided
src/conf/domain_conf.c | 81 +++++++++++++-------------------
src/conf/domain_conf.h | 10 ++--
src/conf/domain_validate.c | 28 ++++++++++-
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_domain.c | 63 ++++++-------------------
src/qemu/qemu_tpm.c | 10 ++--
src/qemu/qemu_validate.c | 87 ++++++++++++++++++++++++-----------
src/security/virt-aa-helper.c | 2 +-
8 files changed, 147 insertions(+), 136 deletions(-)
--
2.35.1
2 years, 8 months
Can RHEL7 VM run remote libvirt commands to Fedora36 host?
by Carol Bouchard
I have a test environment that use to work but no longer does. My
laptop is Fedora36 (libvirt version 8.1.0.2) while the VMs it spawns are
RHEL7 (max libvirt version is 4.5.0). The source of my problem
seems to be that RHEL7 libvirt needs rw socket /var/run/libvirt/libvirt-sock
which no longer exists in fedora36.
The following is successful from RHEL7 VM to laptop:
virsh -d0 --connect
'qemu+ssh://192.168.120.1/system?*socket*=/var/run/libvirt/libvirt-sock-ro'
domstate beaker-test-vm1.beaker
If I change the action from domstate to start, it fails on
error: Failed to start domain beaker-test-vm1.beaker
error: operation forbidden: read only access prevents virDomainCreate
which made me realize ro stands for read-only; however, there is no
libvirt-sock. I tried some of the other socket files without success.
Is there a work-around?
Carol
2 years, 8 months
[PATCH] spec: Remove duplicate check of libvirtd status
by Jim Fehlig
The %posttrans scriptlet checks if libvirtd is active within a
condition that is only executed if libvirtd is active. Remove the
duplicate check.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
This patch contains an improvement Martin suggested while reviewing
another patch to the posttrans scriptlet
https://listman.redhat.com/archives/libvir-list/2022-July/232947.html
The problem of not restarting socket units if libvird is inactive persists,
but it is not clear if socket units need restarted on package update.
libvirt.spec.in | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 9d788b790f..a238edf2aa 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1365,18 +1365,12 @@ then
# own the sockets again when it comes back up. Thus we must
# do this particular ordering, so that we get libvirtd
# running with socket activation in use
- /bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1
- if test $? = 0
- then
- /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || :
-
- /bin/systemctl try-restart \
- libvirtd.socket \
- libvirtd-ro.socket \
- libvirtd-admin.socket >/dev/null 2>&1 || :
-
- /bin/systemctl start libvirtd.service >/dev/null 2>&1 || :
- fi
+ /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || :
+ /bin/systemctl try-restart \
+ libvirtd.socket \
+ libvirtd-ro.socket \
+ libvirtd-admin.socket >/dev/null 2>&1 || :
+ /bin/systemctl start libvirtd.service >/dev/null 2>&1 || :
fi
fi
--
2.36.1
2 years, 8 months
[libvirt PATCH 0/2] qemu: support stateless UEFI firmware
by Daniel P. Berrangé
This is to enable SEV builds of UEFI which provide only a single CODE.fd
file, with not VARS.fd.
Daniel P. Berrangé (2):
conf: support stateless UEFI firmware
qemu: support use of stateless EFI firmware
docs/formatdomain.rst | 9 +++-
src/conf/domain_conf.c | 9 ++++
src/conf/domain_conf.h | 1 +
src/conf/domain_validate.c | 26 ++++++++++
src/conf/schemas/domaincommon.rng | 5 ++
src/qemu/qemu_domain.c | 3 +-
src/qemu/qemu_firmware.c | 48 +++++++++++--------
...-auto-bios-not-stateless.x86_64-latest.err | 1 +
.../firmware-auto-bios-not-stateless.xml | 18 +++++++
...are-auto-bios-stateless.x86_64-latest.args | 32 +++++++++++++
.../firmware-auto-bios-stateless.xml | 18 +++++++
...ware-auto-efi-stateless.x86_64-latest.args | 33 +++++++++++++
.../firmware-auto-efi-stateless.xml | 18 +++++++
.../firmware-manual-bios-not-stateless.err | 1 +
.../firmware-manual-bios-not-stateless.xml | 15 ++++++
.../firmware-manual-bios-stateless.args | 30 ++++++++++++
.../firmware-manual-bios-stateless.xml | 15 ++++++
...nual-efi-nvram-stateless.x86_64-latest.err | 1 +
.../firmware-manual-efi-nvram-stateless.xml | 21 ++++++++
...nvram-template-stateless.x86_64-latest.err | 1 +
...re-manual-efi-nvram-template-stateless.xml | 19 ++++++++
...re-manual-efi-stateless.x86_64-latest.args | 33 +++++++++++++
.../firmware-manual-efi-stateless.xml | 18 +++++++
tests/qemuxml2argvtest.c | 10 ++++
...ware-auto-bios-stateless.x86_64-latest.xml | 34 +++++++++++++
.../firmware-manual-bios-stateless.xml | 25 ++++++++++
.../firmware-manual-bios.xml | 25 ++++++++++
tests/qemuxml2xmltest.c | 3 ++
28 files changed, 451 insertions(+), 21 deletions(-)
create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-not-stateless.x86_64-latest.err
create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-not-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-stateless.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-stateless.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-not-stateless.err
create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-not-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-stateless.args
create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-stateless.x86_64-latest.err
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-template-stateless.x86_64-latest.err
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-nvram-template-stateless.xml
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-stateless.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-stateless.xml
create mode 100644 tests/qemuxml2xmloutdata/firmware-auto-bios-stateless.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/firmware-manual-bios-stateless.xml
create mode 100644 tests/qemuxml2xmloutdata/firmware-manual-bios.xml
--
2.36.1
2 years, 8 months
Entering freeze for libvirt-8.6.0
by Jiri Denemark
I have just tagged v8.6.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
2 years, 8 months
