From fcbe1080a4cb16767cdda788504f9793cbbe0532 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Fri, 19 Sep 2025 09:35:44 +0200 Subject: docs: use the pyvenv version of Meson MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The version in the system might be too old for QEMU; this will be especially true if Rust is going to be enabled by default. Adjust the docs to suggest using pyvenv/bin/meson, which is in fact what the "make" wrappers will be running internally. Reviewed-by: Daniel P. Berrangé Signed-off-by: Paolo Bonzini --- docs/devel/build-system.rst | 2 +- docs/devel/rust.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/devel') diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst index 2c884197a2..6204aa6a72 100644 --- a/docs/devel/build-system.rst +++ b/docs/devel/build-system.rst @@ -450,7 +450,7 @@ are run with ``make bench``. Meson test suites such as ``unit`` can be ran with ``make check-unit``, and ``make check-tcg`` builds and runs "non-Meson" tests for all targets. -If desired, it is also possible to use ``ninja`` and ``meson test``, +If desired, it is also possible to use ``ninja`` and ``pyvenv/bin/meson test``, respectively to build emulators and run tests defined in meson.build. The main difference is that ``make`` needs the ``-jN`` flag in order to enable parallel builds or tests. diff --git a/docs/devel/rust.rst b/docs/devel/rust.rst index 13a20e86a1..2f0ab2e282 100644 --- a/docs/devel/rust.rst +++ b/docs/devel/rust.rst @@ -66,7 +66,7 @@ __ https://mesonbuild.com/Commands.html#devenv As shown above, you can use the ``--tests`` option as usual to operate on test code. Note however that you cannot *build* or run tests via ``cargo``, because they need support C code from QEMU that Cargo does not know about. Tests can -be run via ``meson test`` or ``make``:: +be run via Meson (``pyvenv/bin/meson test``) or ``make``:: make check-rust -- cgit 1.4.1 From 62e82053fc676e9493dc2c2072352634b8cd655d Mon Sep 17 00:00:00 2001 From: Akihiko Odaki Date: Wed, 24 Sep 2025 13:37:20 +0900 Subject: docs/devel: Do not unparent in instance_finalize() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Children are automatically unparented so manually unparenting is unnecessary. Worse, automatic unparenting happens before the instance_finalize() callback of the parent gets called, so object_unparent() calls in the callback will refer to objects that are already unparented, which is semantically incorrect. Remove the instruction to call object_unparent(), and the exception of the "do not call object_unparent()" rule for instance_finalize(). Signed-off-by: Akihiko Odaki Reviewed-by: Daniel P. Berrangé Link: https://lore.kernel.org/r/20250924-use-v4-1-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp Signed-off-by: Paolo Bonzini --- docs/devel/memory.rst | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) (limited to 'docs/devel') diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst index 42d3ca29c4..f22146e56c 100644 --- a/docs/devel/memory.rst +++ b/docs/devel/memory.rst @@ -165,17 +165,14 @@ and finalized one by one. The order in which memory regions will be finalized is not guaranteed. If however the memory region is part of a dynamically allocated data -structure, you should call object_unparent() to destroy the memory region -before the data structure is freed. For an example see VFIOMSIXInfo -and VFIOQuirk in hw/vfio/pci.c. +structure, you should free the memory region in the instance_finalize +callback. For an example see VFIOMSIXInfo and VFIOQuirk in +hw/vfio/pci.c. You must not destroy a memory region as long as it may be in use by a device or CPU. In order to do this, as a general rule do not create or -destroy memory regions dynamically during a device's lifetime, and only -call object_unparent() in the memory region owner's instance_finalize -callback. The dynamically allocated data structure that contains the -memory region then should obviously be freed in the instance_finalize -callback as well. +destroy memory regions dynamically during a device's lifetime, and never +call object_unparent(). If you break this rule, the following situation can happen: @@ -201,9 +198,7 @@ this exception is rarely necessary, and therefore it is discouraged, but nevertheless it is used in a few places. For regions that "have no owner" (NULL is passed at creation time), the -machine object is actually used as the owner. Since instance_finalize is -never called for the machine object, you must never call object_unparent -on regions that have no owner, unless they are aliases or containers. +machine object is actually used as the owner. Overlapping regions and priority -- cgit 1.4.1 From 1f64df25477eff72779b000588cb821c654f26b7 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Mon, 22 Sep 2025 12:45:21 +0200 Subject: docs/code-provenance: clarify scope very early MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The AI policy in QEMU is not about content generators, it is about generated content. Other uses are explicitly not covered. Rename the policy and clarify its scope in the TL;DR section, as a matter of convenience to the reader. Reviewed-by: Daniel P. Berrangé Reviewed-by: Alex Bennée Reviewed-by: Peter Maydell Reviewed-by: Stefan Hajnoczi Signed-off-by: Paolo Bonzini --- docs/devel/code-provenance.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'docs/devel') diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst index b5aae2e253..dc3524ac17 100644 --- a/docs/devel/code-provenance.rst +++ b/docs/devel/code-provenance.rst @@ -285,8 +285,8 @@ Such tools are acceptable to use, provided there is clearly defined copyright and licensing for their output. Note in particular the caveats applying to AI content generators below. -Use of AI content generators -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Use of AI-generated content +~~~~~~~~~~~~~~~~~~~~~~~~~~~ TL;DR: @@ -294,6 +294,10 @@ TL;DR: believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.** + **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 + included in contributions.** + The increasing prevalence of AI-assisted software development results in a number of difficult legal questions and risks for software projects, including QEMU. Of particular concern is content generated by `Large Language Models @@ -322,10 +326,6 @@ The QEMU 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. -- cgit 1.4.1 From 9ceb9b42c8f0f7ea6a4975e67405cfebee249ba8 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Mon, 22 Sep 2025 12:51:37 +0200 Subject: docs/code-provenance: make the exception process more prominent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit QEMU's AI generated content policy does not flesh out the exception process yet. Do it, while at the same time keeping things informal: ask contributors to explain what they would like to use AI for, and let them reach a consensus with the project on why it is credible to claim DCO compliance in that specific scenario. In other words, exceptions do not "solve the AI copyright problem". They take a position that a reasonable contributor could have, and assert that we're comfortable with the argument. Suggested-by: Daniel P. Berrangé Signed-off-by: Paolo Bonzini --- docs/devel/code-provenance.rst | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'docs/devel') diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst index dc3524ac17..6968d54be8 100644 --- a/docs/devel/code-provenance.rst +++ b/docs/devel/code-provenance.rst @@ -331,8 +331,13 @@ 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 -clarifed. In the meanwhile, requests for exceptions to this policy will be -evaluated by the QEMU 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. +clarified. + +Exceptions +^^^^^^^^^^ + +The QEMU project welcomes discussion on any exceptions to this policy, +or more general revisions. This can be done by contacting the qemu-devel +mailing list with details of a proposed tool, model, usage scenario, etc. +that is beneficial to QEMU, while still mitigating issues around compliance +with the DCO. After discussion, any exception will be listed below. -- cgit 1.4.1 From cd64320e1e27168d3796a847bbfde66c8b1116f9 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Mon, 22 Sep 2025 13:14:01 +0200 Subject: docs/code-provenance: AI exceptions are in addition to DCO Using phrasing from https://openinfra.org/legal/ai-policy (with just "commit" replaced by "submission", because we do not submit changes as commits but rather emails), clarify that the contributor remains responsible for its copyright or license status. [This is not my preferred phrasing. I would prefer something lighter like "the "Signed-off-by" label in the contribution gives the author responsibility". But for the sake of not reinventing the wheel I am keeping the exact words from the OpenInfra policy.] Reviewed-by: Peter Maydell Reviewed-by: Stefan Hajnoczi Signed-off-by: Paolo Bonzini --- docs/devel/code-provenance.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'docs/devel') diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst index 6968d54be8..8cdc56f664 100644 --- a/docs/devel/code-provenance.rst +++ b/docs/devel/code-provenance.rst @@ -341,3 +341,9 @@ or more general revisions. This can be done by contacting the qemu-devel mailing list with details of a proposed tool, model, usage scenario, etc. that is beneficial to QEMU, while still mitigating issues around compliance with the DCO. After discussion, any exception will be listed below. + +Exceptions do not remove the need for authors to comply with all other +requirements for contribution. In particular, the "Signed-off-by" +label in a patch submission is a statement that the author takes +responsibility for the entire contents of the patch, including any parts +that were generated or assisted by AI tools or other tools. -- cgit 1.4.1