[PATCH 0/5] Some parsing functions refactor
by Kirill Shchetiniuk
This patch series is supposed to refactor the existing logic of
some parsing functions, changing the previous approach of getting
the string fisrt and then parsing the string itself. Now the
parsing logic is implemented by using the appropriate virXMLProp*
functions.
In some places the error reporter was changed along with the reported
error message and this change was also reflected in exsiting test cases.
Kirill Shchetiniuk (5):
conf: virNetDevVPortProfileParse refactor
conf: virDomainHostdevSubsysMediatedDevDefParseXML refactor
util: virSecretLookupParseSecret refactor
conf: virDomainChrDefParseTargetXML refactor
qemu: qemuDomainObjPrivateXMLParseVcpu refactor
src/conf/domain_conf.c | 28 +---
src/conf/netdev_vport_profile_conf.c | 120 +++++++-----------
src/qemu/qemu_domain.c | 16 +--
src/util/virsecret.c | 19 +--
...mdev-src-address-invalid.x86_64-latest.err | 2 +-
5 files changed, 60 insertions(+), 125 deletions(-)
--
2.49.0
1 day, 19 hours
[PATCH 0/3] bhyve: TCP console support
by Roman Bogorodskiy
Roman Bogorodskiy (3):
bhyve: support serial type 'tcp'
bhyve: increase number of supported consoles to 4
docs: drvbhyve: document TCP console support
docs/drvbhyve.rst | 19 ++++++
src/bhyve/bhyve_capabilities.c | 3 +-
src/bhyve/bhyve_command.c | 42 +++++++++-----
.../bhyvexml2argv-4-consoles.args | 15 +++++
.../bhyvexml2argv-4-consoles.ldargs | 4 ++
.../bhyvexml2argv-4-consoles.xml | 35 +++++++++++
.../bhyvexml2argv-serial-invalid-port.args | 12 ++++
.../bhyvexml2argv-serial-invalid-port.ldargs | 4 ++
.../bhyvexml2argv-serial-invalid-port.xml | 28 +++++++++
.../bhyvexml2argv-serial-tcp.args | 12 ++++
.../bhyvexml2argv-serial-tcp.ldargs | 4 ++
.../bhyvexml2argv-serial-tcp.xml | 27 +++++++++
tests/bhyvexml2argvtest.c | 3 +
.../bhyvexml2xmlout-4-consoles.xml | 58 +++++++++++++++++++
.../bhyvexml2xmlout-serial-tcp.xml | 46 +++++++++++++++
tests/bhyvexml2xmltest.c | 2 +
tests/domaincapsdata/bhyve_basic.x86_64.xml | 1 +
tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 1 +
tests/domaincapsdata/bhyve_uefi.x86_64.xml | 1 +
19 files changed, 301 insertions(+), 16 deletions(-)
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-4-consoles.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-4-consoles.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-4-consoles.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-invalid-port.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-invalid-port.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-invalid-port.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-tcp.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-tcp.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-serial-tcp.xml
create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-4-consoles.xml
create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-serial-tcp.xml
--
2.49.0
2 days
[PATCH v5 0/5] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v5
- dropped the "none" test in qemuxmlactivetest (see commit for
details)
- reordered patches to introduce some tests first, then add
qemu.conf changes
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 (2):
tests: new qemuxmlactive tests for s390x
qemu: add default_cpu_deprecated_features configuration option
Collin Walling (3):
docs: domain: document deprecated_features attribute
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
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 +
...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 | 10 +++-
...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 +
28 files changed, 375 insertions(+), 22 deletions(-)
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.49.0
2 days, 4 hours
[PATCH 0/3] sysinfotest: rename output XMLs with .xml suffix and introduce schema testing
by Peter Krempa
As noticed in:
https://gitlab.com/libvirt/libvirt-go-xml-module/-/issues/10#note_2608097257
This series:
- renames the output files with .xml suffix
- refactors the schema for the domain <sysinfo> to be reusable
- introduces schema to validate the host sysinfo document and tests the
output files in virschematest
Peter Krempa (3):
sysinfotest: Use '.xml' suffix for output files
conf: schemas: Split out common parts of 'sysinfo' schema
schema: Schema validate host '<sysinfo>' XML test documents
src/conf/schemas/domaincommon.rng | 126 +----------
src/conf/schemas/sysinfo.rng | 34 +++
src/conf/schemas/sysinfocommon.rng | 204 ++++++++++++++++++
...nfo.expect => aarch64-gigabytesysinfo.xml} | 0
...o.expect => aarch64-hpe-apollosysinfo.xml} | 0
...nfo.expect => aarch64-moonshotsysinfo.xml} | 0
...rch64sysinfo.expect => aarch64sysinfo.xml} | 0
...rpi2sysinfo.expect => arm-rpi2sysinfo.xml} | 0
.../{armsysinfo.expect => armsysinfo.xml} | 0
.../{ppcsysinfo.expect => ppcsysinfo.xml} | 0
...reqsysinfo.expect => s390-freqsysinfo.xml} | 0
.../{s390sysinfo.expect => s390sysinfo.xml} | 0
.../{x86sysinfo.expect => x86sysinfo.xml} | 0
tests/sysinfotest.c | 2 +-
tests/virschematest.c | 5 +
15 files changed, 251 insertions(+), 120 deletions(-)
create mode 100644 src/conf/schemas/sysinfo.rng
create mode 100644 src/conf/schemas/sysinfocommon.rng
rename tests/sysinfodata/{aarch64-gigabytesysinfo.expect => aarch64-gigabytesysinfo.xml} (100%)
rename tests/sysinfodata/{aarch64-hpe-apollosysinfo.expect => aarch64-hpe-apollosysinfo.xml} (100%)
rename tests/sysinfodata/{aarch64-moonshotsysinfo.expect => aarch64-moonshotsysinfo.xml} (100%)
rename tests/sysinfodata/{aarch64sysinfo.expect => aarch64sysinfo.xml} (100%)
rename tests/sysinfodata/{arm-rpi2sysinfo.expect => arm-rpi2sysinfo.xml} (100%)
rename tests/sysinfodata/{armsysinfo.expect => armsysinfo.xml} (100%)
rename tests/sysinfodata/{ppcsysinfo.expect => ppcsysinfo.xml} (100%)
rename tests/sysinfodata/{s390-freqsysinfo.expect => s390-freqsysinfo.xml} (100%)
rename tests/sysinfodata/{s390sysinfo.expect => s390sysinfo.xml} (100%)
rename tests/sysinfodata/{x86sysinfo.expect => x86sysinfo.xml} (100%)
--
2.50.0
2 days, 8 hours
[RFC 0/4] Implement automatic attachment of the vhostuser port
by yong.huang＠smartx.com
From: Hyman Huang <yong.huang(a)smartx.com>
This series offer an automated method to configure a vhostuser interface
in server mode, simplifying integration with DPDK-enabled Open vSwitch
bridges.
To ensure simplicity and forward compatibility, we introduce openvswitch
backend support for vhostuser interfaces in XML configuration, with an
optional 'autoiface' attribute.
Here is an example of the config for a vhostuser interface that attached
to bridge automatically:
<interface type='vhostuser'>
<mac address='52:54:00:3b:83:1b'/>
<source type='unix' path='/tmp/vhost2.sock' mode='server'/>
<virtualport type='openvswitch'>
<parameters interfaceid='9317d6b7-5fae-4464-a7e9-87d90eff2204'/>
</virtualport>
<backend type='openvswitch' autoiface='yes'>
<parameters bridge='ovsbr-ddpbxnhaq'/>
</backend>
<model type='virtio'/>
<driver queues='5'/>
</interface>
The backend element specifies the backend implementation of the vhostuser
interface type. The type attribute is required and currently supports
supports openvswitch and passt.
If type is openvswitch, the autoiface attribute may be specified (yes
or no), if autoiface is yes, the parameters element bridge attribute
is mandatory. Libvirt will derive the interface name by extracting the
substring after the '/' character in the vhostuser server path, and
attach it to the bridge specified by the bridge attribute.
Please review. Thanks.
Yong
Hyman Huang (4):
qemu_passt: Make logFile backend-specific
conf: Introduce autoiface attribute for vhostuser interface
util: Add iface argument to virNetDevOpenvswitchAddPort
qemu: Implement automatic attachment of the vhostuser port
docs/formatdomain.rst | 37 ++++++++-
src/conf/domain_conf.c | 75 +++++++++++++++++--
src/conf/domain_conf.h | 13 +++-
src/conf/domain_postparse.c | 46 ++++++++++++
src/conf/domain_validate.c | 24 ++++++
src/conf/schemas/domaincommon.rng | 20 +++++
src/lxc/lxc_process.c | 3 +-
src/qemu/qemu_command.c | 3 +
src/qemu/qemu_hotplug.c | 4 +
src/qemu/qemu_interface.c | 46 ++++++++++++
src/qemu/qemu_interface.h | 3 +
src/qemu/qemu_passt.c | 4 +-
src/qemu/qemu_process.c | 4 +
src/util/virnetdevopenvswitch.c | 36 ++++++++-
src/util/virnetdevopenvswitch.h | 10 ++-
src/util/virnetdevtap.c | 3 +-
.../net-vhostuser.x86_64-latest.xml | 10 +++
tests/qemuxmlconfdata/net-vhostuser.xml | 10 +++
18 files changed, 336 insertions(+), 15 deletions(-)
--
2.27.0
2 days, 10 hours
[PATCH v2 0/1] network: introduce Packet Filter firewall backend
by Roman Bogorodskiy
Changes since v1:
- Left only firewall backend changes
- Build network_pf.c only on FreeBSD
- pfAddIPSpecificFirewallRules: error message for lack of IPv6 support
I have also added a basic docs/drvnetwork.rst, but I think it would make
more sense to include it in the follow up series with the bridge driver
changes as with this patch alone pf backend cannot be used just yet.
Roman Bogorodskiy (1):
network: introduce Packet Filter firewall backend
meson.build | 2 +
po/POTFILES | 1 +
src/network/bridge_driver_conf.c | 4 +
src/network/bridge_driver_linux.c | 2 +
src/network/meson.build | 4 +
src/network/network_pf.c | 326 ++++++++++++++++++++++++++++++
src/network/network_pf.h | 26 +++
src/util/virfirewall.c | 4 +-
src/util/virfirewall.h | 2 +
9 files changed, 370 insertions(+), 1 deletion(-)
create mode 100644 src/network/network_pf.c
create mode 100644 src/network/network_pf.h
--
2.49.0
3 days, 7 hours
Support cloning of VMs - part 2
by Mark Cave-Ayland
Hi all,
I'm currently looking at how libvirt can be used to clone a saved VM,
and have been focusing on the previous thread on this topic at
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/YX....
My understanding from reading the thread is that the best way to
approach this is 1) add uuid properties to the relevant objects/devices
in QEMU where the UUID is user-visible, and 2) update libvirt to handle
these properties via XML.
Does this sound correct, or is there any more recent thinking about the
best approach to take?
ATB,
Mark.
5 days, 5 hours
[PATCH] build: prohibit realpath() by syntax-check
by Michal Privoznik
From: Michal Privoznik <mprivozn(a)redhat.com>
We have virFileCanonicalizePath() which calls realpath() but
also is present in our mocks (in contrast to realpath()).
Introduce a syntax-check rule to enforce use of our wrapper.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
build-aux/syntax-check.mk | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 1303a0ce7e..27eabe6565 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -247,6 +247,12 @@ sc_prohibit_canonicalize_file_name:
halt='use virFileCanonicalizePath() instead of canonicalize_file_name()' \
$(_sc_search_regexp)
+sc_prohibit_realpath:
+ @prohibit='\<realpath\(' \
+ exclude='exempt from syntax-check' \
+ halt='use virFileCanonicalizePath() instead of realpath()' \
+ $(_sc_search_regexp)
+
# qsort from glibc has unstable sort ordering for "equal" members
sc_prohibit_qsort:
@prohibit='\<(qsort|qsort_r) *\(' \
@@ -1420,6 +1426,9 @@ exclude_file_name_regexp--sc_prohibit_nonreentrant = \
exclude_file_name_regexp--sc_prohibit_canonicalize_file_name = \
^(build-aux/syntax-check\.mk|tests/virfilemock\.c)$$
+exclude_file_name_regexp--sc_prohibit_realpath = \
+ ^(build-aux/syntax-check\.mk|src/cpu_map/sync_qemu_features_i386\.py|tests/virfilemock\.c)$$
+
exclude_file_name_regexp--sc_prohibit_raw_allocation = \
^(docs/advanced-tests\.rst|src/util/viralloc\.[ch]|examples/.*|tests/(securityselinuxhelper|(vircgroup|nss)mock|commandhelper)\.c|tools/wireshark/src/packet-libvirt\.c|tools/nss/libvirt_nss(_leases|_macs)?\.[ch])$$
--
2.49.0
5 days, 7 hours
[PATCH v4 00/23] 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].
* Test
Tested with upstream qemu v10.0.0-1724-gf9a3def17b
shutdown/reboot/reset with virsh
shutdown/reboot trigger in guest
shutdown with on_poweroff=destroy/restart
reboot with on_reboot=destroy/restart
GUEST_PANICKED event processing
auto firmware matching
* Patch organization
- patch 1-4: Some preparing work
- patch 5-6: Support query of TDX capabilities
- patch 7-15: Add TDX type to launchsecurity framework
- patch 16-21: Add reboot/reset support to TDX guest
- patch 22: Add conf test dump/cases for '+inteltdx' variant
- patch 23: Add docs
TODO:
- add reconnect logic in virsh command
[1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v4
Thanks
Zhenzhong
Changelog:
v4:
- add QGS config to qemuxmlconftest (Daniel)
- use 0x10000000 policy value in test as debug isn't supported yet (Daniel)
- s/mrowner/mrOwner/ s/mrownerconfig/mrOwnerConfig/ (Daniel)
- s/quoteGenerationSocket/quoteGenerationService/ (Daniel)
- handle "GUEST_PANICKED" event of type tdx (Daniel)
- add automatic firmware matching (Daniel)
v3:
- fix a hiden failure in qemuBuildTDXQGSCommandLine() (Peter Krempa)
- avoid the use of the ternary operator (Peter Krempa)
- add capability test dump before capability introduced (Peter Krempa)
- change tests version number from 11.0.0 to 10.1.0 (Peter Krempa)
v2:
- add capability and xmlconf test (Peter Krempa)
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 (23):
tools: Secure guest check for Intel in virt-host-validate
qemu: Check if INTEL Trust Domain Extention support is enabled
qemucapabilitiesdata: Document '+inteltdx' variant
qemucapabilitiestest: Add data for the qemu-10.1.0 dev cycle on x86_64
for the '+inteltdx' variant
qemu: Add QEMU_CAPS_TDX_GUEST 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
qemu: log the crash information for TDX
qemu_firmware: Pick the right firmware for TDX guests
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
qemuxmlconftest: Add latest version of 'launch-security-tdx*' test
data
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 | 43 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 11 +-
src/qemu/qemu_firmware.c | 20 +
src/qemu/qemu_monitor.c | 50 +-
src/qemu/qemu_monitor.h | 13 +-
src/qemu/qemu_monitor_json.c | 38 +-
src/qemu/qemu_namespace.c | 1 +
src/qemu/qemu_process.c | 104 +-
src/qemu/qemu_process.h | 2 +
src/qemu/qemu_validate.c | 45 +
src/security/security_dac.c | 2 +
.../qemu_10.1.0-q35.x86_64+inteltdx.xml | 783 +
.../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 7 +-
.../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 1830 +
.../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 6 +-
.../qemu_10.1.0.x86_64+inteltdx.xml | 783 +
tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 7 +-
tests/domaincapsmock.c | 3 +-
tests/qemucapabilitiesdata/README.rst | 5 +
.../caps_10.1.0_x86_64+inteltdx.replies | 44552 ++++++++++++++++
.../caps_10.1.0_x86_64+inteltdx.xml | 3585 ++
.../caps_10.1.0_x86_64.xml | 1 +
.../caps.x86_64+inteltdx.xml | 29 +
.../firmware/60-edk2-ovmf-x64-inteltdx.json | 1 +
...h-security-tdx.x86_64-latest+inteltdx.args | 44 +
...ch-security-tdx.x86_64-latest+inteltdx.xml | 75 +
tests/qemuxmlconfdata/launch-security-tdx.xml | 28 +
tests/qemuxmlconftest.c | 3 +
tools/virsh-domain-event.c | 6 +-
tools/virt-host-validate-common.c | 31 +-
tools/virt-host-validate-common.h | 1 +
47 files changed, 52372 insertions(+), 18 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64+inteltdx.xml
create mode 100644 tests/domaincapsdata/qemu_10.1.0-tcg.x86_64+inteltdx.xml
create mode 100644 tests/domaincapsdata/qemu_10.1.0.x86_64+inteltdx.xml
create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.replies
create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.xml
create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+inteltdx.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.args
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.xml
--
2.47.1
5 days, 10 hours
[libvirt PATCH] docs: hacking: Define policy forbidding use of AI code generators
by Pavel Hrdina
This policy is a copy of what QEMU project is using [1] as there is no
reason to use different policy, only modification is changing the
project name and link to DCO.
[1] <https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-con...>
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
docs/hacking.rst | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/docs/hacking.rst b/docs/hacking.rst
index 825b8b83d2..5f0f867b9f 100644
--- a/docs/hacking.rst
+++ b/docs/hacking.rst
@@ -90,6 +90,58 @@ formal ID documents, but should not be anonymous, nor misrepresent
who you are. The presence of this line attests that the contributor
has read the above linked DCO and agrees with its statements.
+Use of AI content generators
+============================
+
+TL;DR:
+
+ **Current libvirt project policy is to DECLINE any contributions which are
+ believed to include or derive from AI generated content. This includes
+ ChatGPT, Claude, Copilot, Llama and similar tools.**
+
+The increasing prevalence of AI-assisted software development results in a
+number of difficult legal questions and risks for software projects, including
+libvirt. Of particular concern is content generated by `Large Language Models
+<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
+
+The libvirt community requires that contributors certify their patch submissions
+are made in accordance with the rules of the `Developer Certificate of
+Origin`_.
+
+To satisfy the DCO, the patch contributor has to fully understand the
+copyright and license status of content they are contributing to libvirt. With
+AI content generators, the copyright and license status of the output is
+ill-defined with no generally accepted, settled legal foundation.
+
+Where the training material is known, it is common for it to include large
+volumes of material under restrictive licensing/copyright terms. Even where
+the training material is all known to be under open source licenses, it is
+likely to be under a variety of terms, not all of which will be compatible
+with libvirt's licensing requirements.
+
+How contributors could comply with DCO terms (b) or (c) for the output of AI
+content generators commonly available today is unclear. The libvirt project is
+not willing or able to accept the legal risks of non-compliance.
+
+The libvirt project thus requires that contributors refrain from using AI
+content generators on patches intended to be submitted to the project, and
+will decline any contribution if use of AI is either known or suspected.
+
+This policy does not apply to other uses of AI, such as researching APIs or
+algorithms, static analysis, or debugging, provided their output is not to be
+included in contributions.
+
+Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
+ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
+generation agents which are built on top of such tools.
+
+This policy may evolve as AI tools mature and the legal situation is
+clarified. In the meanwhile, requests for exceptions to this policy will be
+evaluated by the libvirt project on a case by case basis. To be granted an
+exception, a contributor will need to demonstrate clarity of the license and
+copyright status for the tool's output in relation to its training model and
+code, to the satisfaction of the project maintainers.
+
Further reading
===============
--
2.49.0
5 days, 20 hours
