July 2025 - Devel - libvirt List Archives

[PATCH 0/1] qemu qapi: SIGSEGV small fix
by Nikolai Barybin 16 Jul '25

16 Jul '25

Hello everyone! When implementing some custom qemu capability I cought this bug when some string with '*' pattern is not contained in schema, and virQEMUQAPISchemaTraverseObject passes NULL ptr to virJSONValueObjectHasKey. Nikolai Barybin (1): qemu: qapi: fix potential SIGSEGV in virQEMUQAPISchemaTraverseObject() src/qemu/qemu_qapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.43.5

2 4

[libvirt PATCH] conf: schemas: add sysinfocommon.rng into list of installed schemas
by Pavel Hrdina 15 Jul '25

15 Jul '25

From: Pavel Hrdina <phrdina(a)redhat.com> Fixes: 918594b419ea3944220fcbab6cf4f1ce7d81e609 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/conf/schemas/meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/src/conf/schemas/meson.build b/src/conf/schemas/meson.build index b293373085..7ec625b8db 100644 --- a/src/conf/schemas/meson.build +++ b/src/conf/schemas/meson.build @@ -25,6 +25,7 @@ schema_files = [ 'storagepoolcaps.rng', 'storagepool.rng', 'storagevol.rng', + 'sysinfocommon.rng', ] install_data(schema_files, install_dir: pkgdatadir / 'schemas') -- 2.50.1

2 2

[PATCH 0/5] Some parsing functions refactor
by Kirill Shchetiniuk 14 Jul '25

14 Jul '25

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

2 10

[PATCH 0/3] bhyve: TCP console support
by Roman Bogorodskiy 14 Jul '25

14 Jul '25

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 6

[PATCH 0/3] sysinfotest: rename output XMLs with .xml suffix and introduce schema testing
by Peter Krempa 14 Jul '25

14 Jul '25

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 4

Support cloning of VMs - part 2
by Mark Cave-Ayland 11 Jul '25

11 Jul '25

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/YXN2…. 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.

3 8

[PATCH] build: prohibit realpath() by syntax-check
by Michal Privoznik 11 Jul '25

11 Jul '25

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

2 1

[libvirt PATCH] docs: hacking: Define policy forbidding use of AI code generators
by Pavel Hrdina 10 Jul '25

10 Jul '25

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-conte…> 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

3 3

[PATCH] NEWS: Mention switch to virtio-scsi on ARM
by Jim Fehlig 10 Jul '25

10 Jul '25

From: Jim Fehlig <jfehlig(a)suse.com> Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index d8bd2559f4..59494cb380 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -19,6 +19,12 @@ v11.6.0 (unreleased) * **Improvements** + * qemu: Change default SCSI controller model to ``virtio-scsi`` for ARM + + The previous default of ``lsilogic`` is unsupported by modern operating + systems. ``virtio-scsi`` is a more suitable default for ARM ``virt`` + machine types. + * **Bug fixes** -- 2.43.0

2 2

How to process after sending a patch assisted with AI
by Enrique Llorente Pastora 10 Jul '25

10 Jul '25

Hi, How should I process after sending a patch that has code generated by AI [1] ? Is creating a new AI free version with some explanation enough to prevent the submission from being suspicious ? Possible example for explanation would be "I am using how qemu:commandline is implemented as inspiration for the feature and not AI was used to generate code or tests as opposed to v3". BR. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/ZNR… -- Quique Llorente CNV networking Senior Software Engineer Red Hat EMEA ellorent(a)redhat.com @RedHat Red Hat Red Hat

1 0