Re: [RFC PATCH 08/10] .agents/skills: add qemu-issue-triage agent skill

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, May 05, 2026 at 06:01:03PM +0100, Alex Bennée wrote:
>> While triaging the issue tracker I wondered if this would be a
>> suitable job for an AI agent. Unfortunately the OSS program doesn't
>> give any credits to run agents in gitlab. However I do have access to
>> models from my editor and ECA so I built one and tested it on a few
>> issues.
>> 
>> Obviously this can't apply as is because it probably encodes too much
>> of my local setup (using pass for API keys) and uses the ECA as my
>> preferred coding agent. I assume at some point there will be agreement
>> between all the agents where skill live.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> ..snip..
>
>> diff --git a/.agents/skills/qemu-issue-triage/assets/labels.txt
>> b/.agents/skills/qemu-issue-triage/assets/labels.txt
>> new file mode 100644
>> index 00000000000..d329f34183d
>> --- /dev/null
>> +++ b/.agents/skills/qemu-issue-triage/assets/labels.txt
>
> Seeing our labels listed like this triggers my urge to "tidy" :-)
>
> Don't take anything below to be a complaint / blocker about this patch.
> This patch is fine in so much as it faithfully represents the mess we
> have created in gitlab.
>
>> @@ -0,0 +1,133 @@
>> +# SPDX-License-Identifier: GPL-2.0-or-later
>> +ACPI                       Power Management related (ACPI / SMBIOS / HEST / GHES)
>> +Audio Audio devices; both backend (host audio) and frontend (guest
>> audio)
>
> Mixing frontend and backend is a bad idea in general IMHO.
>
> I feel like we should also have an explicit label for each backend, for
> both audio and every other backend type.

Backend: chardev
Backend: audio
?

I suspect the block backends are special enough they should stay part of
block: - what other backends do we have?

>
>> +Audit Tooling A group for bugs and issues found via automated
>> tooling such as fuzzing, sanitizers or AI
>> +Audit Tooling::AI For bugs found with AI assisted tools such as
>> Mythos and other similar things
>> +Audit Tooling::Fuzzer Issues found via fuzzing. For security
>> issues, please consult
>> https://www.qemu.org/contribute/security-process/
>> +Audit Tooling::Sanitizer For issues found using sanitizers such as
>> asan, lsan and tsan
>
> Labels with "::" are mutually exculsive, which is possibly not
> what we want here ?  Should the first thing be 'Audit Tooling::Other'
> instead of unqualified ?

I've added that, as well as Audit Tooling::Static Analysis for Coverity.

>
>> +Bite Sized Candidates for first contributions; see also
>> https://wiki.qemu.org/Contribute/BiteSizedTasks
>> +Build System               configure, make, Meson, ninja, gcc, clang, ccache, etc.
>> +CI                         Continuous Integration; gitlab, travis, patchew, etc.
>> +CLI                        Command Line Interface
>> +Chardev                    Character device backends and related issues
>
> We should have per-backend labels
>
>> +Closed::Duplicate There is already another ticket that is about the
>> same issue
>> +Closed::Fixed              The issue was fixed. Yay!
>> +Closed::Invalid            This issue was not really a problem
>> +Closed::NotOurBug This is a bug, but not a bug in QEMU. Please
>> report it and/or include a link to the report.
>> +Closed::NotReproducible    This issue was not reproducible
>> +Closed::UnbackedFeature    Nobody was willing to work on this feature request
>> +Closed::WontFix The issue was acknowledged, but the fix would be
>> too complex, too expensive, or would introduce other problems.
>> +Cryptography
>> +Documentation Sphinx documentation, man pages, the wiki, --help
>> output, etc.
>> +GDB                        Issues relating to using GDB via the gdbstub
>> +GUI Graphical User Interface (gtk, SDL, curses, VNC, spice, ...)
>> +GUI::Cocoa                 Cocoa
>> +GUI::DBus                  DBus
>> +GUI::GTK
>> +GUI::SDL                   SDL
>> +GUI::SPICE                 SPICE
>
> spice is duplicated later

Prompt: "find all the issues with the "spice" label and label them with the GUI::SPICE label instead"

the result was:

  general: relabling spice issues (5 steps, 13.5K / 1M) ✅ 1m 26s

  I have successfully relabeled all GitLab issues in the `qemu-project/qemu` repository by replacing the "spice" label with the "GUI::SPICE" label.

  ### Summary of Actions:
  - **Total Issues Updated**: 21 (including both open and closed issues).
  - **Relabeling**: Removed the `spice` label and applied the `GUI::SPICE` label to each identified issue.
  - **Verification**: Confirmed that `glab issue list --label spice` now returns no results, while `glab issue list --label "GUI::SPICE"` includes all updated issues.

  ### Updated Issues:
  The following 21 issues were updated: 
  `3148`, `3070`, `2860`, `2667`, `2639`, `2561`, `2411`, `2335`, `2282`, `2071`, `1926`, `1829`, `1778`, `1777`, `1553`, `1549`, `1431`, `1426`, `1285`, `681`, `232`.

about 0.08p in inference costs.

>
>> +GUI::VNC
>
> I'd probably suggest "ui" as the prefix to match the dir / subsystem
> name.
>
> Also probably use ":" instead of "::" as there could be cases where
> a bug affects multiple UIs.
>
>> +Guest Agent Issues related to the qemu-guest-agent binary.
>> https://wiki.qemu.org/Features/GuestAgent
>> +Hard

I think there is 1 bug that is Hard.

>> +Launchpad                  Issues migrated from Launchpad
>> +Migration
>
> Surprised we don't want more categories here
>
>> +Modules
>> +Networking
>> +Python                     Python library issues (./python/)
>> +QAPI/QMP                   QEMU API / QEMU Machine Protocol, HMP and CLI, etc.
>> +QOM                        QEMU Object Model
>> +Regression
>> +Security
>> +Semihosting Semihosting calls provide a simple ABI for early
>> bring-up of embedded devices and provide a way to output to the
>> console and do basic file i/o while being debugged
>> +Softfloat                  QEMU's FPU emulation code (TCG only)
>> +Stable::can't fix The bug was reported on a stable branch but the
>> fix is too invasive for backporting
>> +Stable::obsolete The bug was reported on a stable branch that is
>> not maintained anymore
>> +Stable::to backport The bug was reported on a stable branch and
>> needs to be backported on the next release from the branch
>> +Storage                    Block subsystem, Storage devices, etc.
>> +TCG plugins                Anything related to the TCG plugins feature
>
> Perhaps accel:tcg:plugins ?
>

Plugins currently implies accel:tcg but I'm not sure it is directly
accelerator related. Some of the run-loop hooks are TCG agnostic.

>> +TestCase                   The report includes a testcase
>> +Tests qtests, iotests, acceptance tests, VM tests, docker tests,
>> and more.
>> +USB
>> +VFIO
>
> This annoying sorting of all uppercase, then all lowercase is
> present in the gitlab UI too
>
> https://gitlab.com/qemu-project/qemu/-/labels
>
> We should probalby be universally lowercase, so that sorting is
> sensible.
>
>> +accel: HAX                 Intel's Hardware Accelerated Execution Manager (HAXM)
>> +accel: HVF                 Apple Hypervisor Framework
>> +accel: KVM                 Linux Kernel-based Virtual Machine
>> +accel: TCG                 QEMU Tiny Code Generator
>> +accel: WHPX                Microsoft Windows Hypervisor Platform (WHPX)
>> +accel: Xen                 Xen Hypervisor
>
> We're inconsistent in whether we use a space after ":". Here we do,
> below we don't.
>
>> +block:9p                   The 9p network file system
>> +block:NVMe
>
> These two are not like the others under 'block:'. 'NVMe' is frontend device,
> and 9p is a filesystem. I'd assume 'block:' applies to block/*.c
>
>> +block:curl
>> +block:nbd
>> +block:nfs                  Issues related to the NFS backend
>> +block:qcow2
>> +block:ssh
>> +block:vmdk
>
> Probably want a "block:core" for stuff not specific to one of the listed
> backends.

I'll let the block guys fix this up.

>
>> +bsd-user
>> +device: PCI
>> +device: TPM                Trusted Platform Module (TPM) devices
>> +device:graphics Issues relating to display device emulation, or
>> rendering in general. See also "GUI".
>> +device:input               Keyboards, Mice, Touchscreens, HIDs, etc.
>> +device:iommu               IOMMU and SMMU
>> +device:pflash              Parallel NOR flashes emulation
>> +device:sdmmc               SD or (e)MMC cards emulation
>> +device:virtio virtio-related issues.
>> https://www.linux-kvm.org/page/Virtio
>> +device:watchdog
>
> Here we sometimes have a space after : and sometimes don't
>
>
>> +efi                        EFI firmware related issues
>> +flaky-ci                   For test cases that are flaky when run under our CI
>> +gitlab
>
> So should we be using "CI" or "gitlab" for CI issues :)
>
> Probably we should have:
>
>   ci:gitlab
>   ci:flaky
>
>> +guest: AIX
>> +guest: BSD                 Guest OS is BSD (NetBSD/FreeBSD/OpenBSD/etc)
>> +guest: Linux               Guest OS is Linux/Linux-based
>> +guest: Windows             Microsoft Windows guest
>> +guest: macOS               Apple macOS / Darwin as  guest OS
>> +guest: os2
>> +host: aarch64              Bugs reproducible on AArch64 hosts
>> +host: arm                  Bugs reproducible on ARM hosts
>> +host: loongarch64          Bugs reproducible on LoongArch64 hosts.
>> +host: mips                 Bugs reproducible on MIPS hosts
>> +host: ppc                  Bugs reproducible on Power hosts
>> +host: riscv                Bugs reproducible on RISC-V hosts
>> +host: s390                 Bugs reproducible on s390 hosts
>> +host: sparc64              Bugs specific to Sparc64 hosts
>> +host: x86                  Bugs reproducible on x86 hosts
>> +host:32bit These are mostly TCG related bugs where we sometimes
>> struggle with emulating larger guests, especially atomic and address
>> space issues.
>
> More space inconsistency
>
>> +hostos: BSD                FreeBSD, OpenBSD, NetBSD, and derivatives as host OSes
>> +hostos: Linux Linux-based host operating systems (Fedora,
>> RHEL/CentOS, Debian, Ubuntu, openSuSE et al)
>> +hostos: Windows            Microsoft Windows host OS
>> +hostos: macOS              Apple macOS / Darwin as a host OS
>> +icount issues relating to icount, deterministic execution and
>> record/replay functionality
>
> Perhaps accel:tcg:icount  ?
>
>> +kind: Not user visible
>
> What's this for, and why : instead of :: ?

No idea - is this the mechanism we use to hide live security issues?

>
>> +kind::Bug                  Bug or defect in functionality.
>> +kind::Feature Request      Feature request or new functionality.
>> +kind::Task                 Research, investigations, and miscellaneous issues.
>> +libvfio-user
>> +linux-user
>> +qemu-img
>
> Should we have a "tools:qemu-img", and "tools:...." for everything
> else too ?
>
>> +spice
>
> Redundant with 'GUI::SPICE"
>
>> +sysadmin
>
> Any idea what this is supposed to refer to ?

there is one issue where CI runs fail on some runners and not others. I
added some flavour text.

>
>> +target: alpha              DEC Alpha [alpha]
>> +target: arm                Arm AArch32 or AArch64 [arm, aarch64]
>> +target: avr                Atmel AVR [avr]
>> +target: hexagon            Qualcomm Hexagon [hexagon]
>> +target: hppa Hewlett-Packard Precision Architecture; HP/HP, PA-RISC
>> [hppa]
>> +target: i386               Intel/AMD x86 [i386, x86_64]
>> +target: loongarch          loongarch64 target architecture
>> +target: m68k               Motorola 68000 [m68k]
>> +target: microblaze         Xilinx MicroBlaze [microblaze, microblazeel]
>> +target: mips               MIPS [mips, mipsel, mips64, mips64el]
>> +target: nios2              Altera Nios II [nios2]
>> +target: openrisc           OpenRISC [or1k]
>> +target: ppc                IBM Power Architecture, PowerPC [ppc, ppc64, ppc64le]
>> +target: riscv              RISC-V [riscv32, riscv64]
>> +target: rx                 Renesas RX [rx]
>> +target: s390x              IBM Z, SystemZ, zSeries [s390x]
>> +target: sh4                Renesas SuperH [sh4, sh4eb]
>> +target: sparc              Sun Microsystems SPARC [sparc, sparc64]
>> +target: tricore            Infineon TriCore [tricore]
>> +target: xtensa             Tensilica Xtensa [xtensa, xtensaeb]
>> +workflow::Confirmed        Bugs that have been confirmed and reproduced.
>> +workflow::In Progress      Someone is working on this issue.
>> +workflow::Needs Info       Issue has insufficient information to verify.
>> +workflow::Patch available  A patch is available
>> +workflow::Triaged          Issue has been triaged and given a topic label.
>
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro