* QEMU Sashiko
@ 2026-10-28 23:32 Alistair
2026-10-29 8:06 ` Philippe Mathieu-Daudé
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Alistair @ 2026-10-28 23:32 UTC (permalink / raw)
To: qemu-devel
Hey,
Sashiko just merged initial support for QEMU [1].
For those who don't know, Sashiko is a LLM powered review bot used for
the Linux kernel. When people send patches to LKML Sashiko reviews the
patches and responds to the mailing list with any issue that it finds.
Like all LLM tools, it is both useful, but also verbose, prone to
hallucinations and misses things (like humans do to though). The
general consensus in the kernel community is that it's a useful and
valuable tool.
Sashiko is just a Rust application and prompts, it doesn't include a
LLM and you can use a range of different LLM backends.
Google sponsors the development and runs a Linux instance. So you can
see the hosted Linux instance here: https://sashiko.dev/ and it uses
Gemini for the LLM which Google pays for. It seems like there is also a
GCC one starting up.
The cool thing about Sashiko though is you can run it locally as well,
so you can use it to test your patches before sending them to LKML, as
long as you have a LLM backend you can use.
So, now that Sashiko also supports QEMU there are two exciting use
cases:
1. Developers can run it locally to review their patches before sending
them to the list. This can catch issues before sending patches
2. Maintainers can run an instance to review patches. How you set this
up depends on the maintainer and how many tokens you have. Pointing it
at the list directly and running it for all patches might be too much,
but some combination of manually triggering it for certain patches
seems to work well. The Settings.toml file can be setup based on what
you want to do.
The hope with this is to save maintainers time as Sashiko can catch
issues without requiring much time from a maintainer.
QEMU support in Sashiko is very new, so it will take some tweaking to
improve things, but it is at least a good starting place.
1:
https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
Alistair
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-28 23:32 QEMU Sashiko Alistair
@ 2026-10-29 8:06 ` Philippe Mathieu-Daudé
2026-10-29 13:29 ` Fabiano Rosas
2026-10-29 12:50 ` Alex Bennée
` (2 subsequent siblings)
3 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2026-10-29 8:06 UTC (permalink / raw)
To: Alistair, qemu-devel; +Cc: Zhao Liu
On 29/10/26 00:32, Alistair wrote:
> Hey,
>
> Sashiko just merged initial support for QEMU [1].
>
> For those who don't know, Sashiko is a LLM powered review bot used for
> the Linux kernel. When people send patches to LKML Sashiko reviews the
> patches and responds to the mailing list with any issue that it finds.
>
> Like all LLM tools, it is both useful, but also verbose, prone to
> hallucinations and misses things (like humans do to though). The
> general consensus in the kernel community is that it's a useful and
> valuable tool.
>
> Sashiko is just a Rust application and prompts, it doesn't include a
> LLM and you can use a range of different LLM backends.
>
> Google sponsors the development and runs a Linux instance. So you can
> see the hosted Linux instance here: https://sashiko.dev/ and it uses
> Gemini for the LLM which Google pays for. It seems like there is also a
> GCC one starting up.
>
> The cool thing about Sashiko though is you can run it locally as well,
> so you can use it to test your patches before sending them to LKML, as
> long as you have a LLM backend you can use.
>
> So, now that Sashiko also supports QEMU there are two exciting use
> cases:
>
> 1. Developers can run it locally to review their patches before sending
> them to the list. This can catch issues before sending patches
>
> 2. Maintainers can run an instance to review patches. How you set this
> up depends on the maintainer and how many tokens you have. Pointing it
> at the list directly and running it for all patches might be too much,
> but some combination of manually triggering it for certain patches
> seems to work well. The Settings.toml file can be setup based on what
> you want to do.
>
> The hope with this is to save maintainers time as Sashiko can catch
> issues without requiring much time from a maintainer.
>
> QEMU support in Sashiko is very new, so it will take some tweaking to
> improve things, but it is at least a good starting place.
>
> 1:
> https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
I'm glad you added projects/qemu/ directory there; some time ago
Zhao and myself tried to leverage LLM to review QEMU and reduce
maintenance burden but there was little community interest and
some negative feedback so we didn't pursued on the list.
https://lore.kernel.org/qemu-devel/afxbDjQEWJZ6P9oe@redhat.com/
https://lore.kernel.org/qemu-devel/arpINtziWCbjENeo@intel.com/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-28 23:32 QEMU Sashiko Alistair
2026-10-29 8:06 ` Philippe Mathieu-Daudé
@ 2026-10-29 12:50 ` Alex Bennée
2026-10-29 12:58 ` Daniel P. Berrangé
2026-10-29 13:35 ` Brian Cain
3 siblings, 0 replies; 7+ messages in thread
From: Alex Bennée @ 2026-10-29 12:50 UTC (permalink / raw)
To: Alistair; +Cc: qemu-devel, Ben Copeland
Alistair <alistair@alistair23.me> writes:
> Hey,
>
> Sashiko just merged initial support for QEMU [1].
>
> For those who don't know, Sashiko is a LLM powered review bot used for
> the Linux kernel. When people send patches to LKML Sashiko reviews the
> patches and responds to the mailing list with any issue that it finds.
>
> Like all LLM tools, it is both useful, but also verbose, prone to
> hallucinations and misses things (like humans do to though). The
> general consensus in the kernel community is that it's a useful and
> valuable tool.
Linaro has been experimenting with AI reviews as well with our
patchpilot tool. You can see an example of its output here:
https://patchpilot.linaro.org/run/2749c6de82c1-2#stage=review
> Sashiko is just a Rust application and prompts, it doesn't include a
> LLM and you can use a range of different LLM backends.
>
> Google sponsors the development and runs a Linux instance. So you can
> see the hosted Linux instance here: https://sashiko.dev/ and it uses
> Gemini for the LLM which Google pays for. It seems like there is also a
> GCC one starting up.
I don't suppose anyone is interested in sponsoring the token cost? The
main reason we haven't deployed it beyond our engineers is the cost
implications. I assume the reason Google can afford to run it is a
vested interest in the kernel and owning their own inference
infrastructure.
> The cool thing about Sashiko though is you can run it locally as well,
> so you can use it to test your patches before sending them to LKML, as
> long as you have a LLM backend you can use.
>
> So, now that Sashiko also supports QEMU there are two exciting use
> cases:
>
> 1. Developers can run it locally to review their patches before sending
> them to the list. This can catch issues before sending patches
>
> 2. Maintainers can run an instance to review patches. How you set this
> up depends on the maintainer and how many tokens you have. Pointing it
> at the list directly and running it for all patches might be too much,
> but some combination of manually triggering it for certain patches
> seems to work well. The Settings.toml file can be setup based on what
> you want to do.
Be warned if you enable with an expensive model like Claude a moderate
patch review can very quickly add up to $20-$50 of tokens.
> The hope with this is to save maintainers time as Sashiko can catch
> issues without requiring much time from a maintainer.
It depends. Some times you end up reading quite a big wall of model
reasoning text and you end up none the wiser to what it actually found
wrong. On the other hand given engineers are expensive you don't need to
save much of their time to make the token cost worthwhile.
That said I personally feel one under explored area is using cheaper
models and a common code smells skill that could be useful in
identifying the obvious nits and mistakes that often come up in the
first pass review. That would leave maintainers free to spend more time
thinking about the actual logic and design of a patch.
If it was embedded in skills we could hopefully get contributors to run
reviews locally with their own agents before posting a series and
avoiding the normal RFC feedback of nits and fixes. It would be
effectively a slightly smarter checkpatch.
>
> QEMU support in Sashiko is very new, so it will take some tweaking to
> improve things, but it is at least a good starting place.
>
> 1:
> https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
>
> Alistair
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-28 23:32 QEMU Sashiko Alistair
2026-10-29 8:06 ` Philippe Mathieu-Daudé
2026-10-29 12:50 ` Alex Bennée
@ 2026-10-29 12:58 ` Daniel P. Berrangé
2026-10-29 13:35 ` Brian Cain
3 siblings, 0 replies; 7+ messages in thread
From: Daniel P. Berrangé @ 2026-10-29 12:58 UTC (permalink / raw)
To: Alistair; +Cc: qemu-devel
On Thu, Oct 29, 2026 at 09:32:12AM +1000, Alistair wrote:
> Hey,
>
> Sashiko just merged initial support for QEMU [1].
snip
> So, now that Sashiko also supports QEMU there are two exciting use
> cases:
>
> 1. Developers can run it locally to review their patches before sending
> them to the list. This can catch issues before sending patches
>
> 2. Maintainers can run an instance to review patches. How you set this
> up depends on the maintainer and how many tokens you have. Pointing it
> at the list directly and running it for all patches might be too much,
> but some combination of manually triggering it for certain patches
> seems to work well. The Settings.toml file can be setup based on what
> you want to do.
>
> The hope with this is to save maintainers time as Sashiko can catch
> issues without requiring much time from a maintainer.
>
> QEMU support in Sashiko is very new, so it will take some tweaking to
> improve things, but it is at least a good starting place.
>
> 1:
> https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
This has added a large set of documents about QEMU's internals to a
3rd party repository. Is there not a way to have Sashiko acquire
all the review policies from qemu.git directly ?
IMHO, the QEMU project/maintauners really ought to own & update review
guidelines directly in our repo, especially as we're already intending
to add lots of relevant information to qemu.git for AI usage in general.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-29 8:06 ` Philippe Mathieu-Daudé
@ 2026-10-29 13:29 ` Fabiano Rosas
0 siblings, 0 replies; 7+ messages in thread
From: Fabiano Rosas @ 2026-10-29 13:29 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Alistair, qemu-devel; +Cc: Zhao Liu
Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> writes:
> On 29/10/26 00:32, Alistair wrote:
>> Hey,
>>
>> Sashiko just merged initial support for QEMU [1].
>>
>> For those who don't know, Sashiko is a LLM powered review bot used for
>> the Linux kernel. When people send patches to LKML Sashiko reviews the
>> patches and responds to the mailing list with any issue that it finds.
>>
>> Like all LLM tools, it is both useful, but also verbose, prone to
>> hallucinations and misses things (like humans do to though). The
>> general consensus in the kernel community is that it's a useful and
>> valuable tool.
>>
>> Sashiko is just a Rust application and prompts, it doesn't include a
>> LLM and you can use a range of different LLM backends.
>>
>> Google sponsors the development and runs a Linux instance. So you can
>> see the hosted Linux instance here: https://sashiko.dev/ and it uses
>> Gemini for the LLM which Google pays for. It seems like there is also a
>> GCC one starting up.
>>
>> The cool thing about Sashiko though is you can run it locally as well,
>> so you can use it to test your patches before sending them to LKML, as
>> long as you have a LLM backend you can use.
>>
>> So, now that Sashiko also supports QEMU there are two exciting use
>> cases:
>>
>> 1. Developers can run it locally to review their patches before sending
>> them to the list. This can catch issues before sending patches
>>
>> 2. Maintainers can run an instance to review patches. How you set this
>> up depends on the maintainer and how many tokens you have. Pointing it
>> at the list directly and running it for all patches might be too much,
>> but some combination of manually triggering it for certain patches
>> seems to work well. The Settings.toml file can be setup based on what
>> you want to do.
>>
>> The hope with this is to save maintainers time as Sashiko can catch
>> issues without requiring much time from a maintainer.
>>
>> QEMU support in Sashiko is very new, so it will take some tweaking to
>> improve things, but it is at least a good starting place.
>>
>> 1:
>> https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
>
> I'm glad you added projects/qemu/ directory there; some time ago
> Zhao and myself tried to leverage LLM to review QEMU and reduce
> maintenance burden but there was little community interest and
> some negative feedback so we didn't pursued on the list.
> https://lore.kernel.org/qemu-devel/afxbDjQEWJZ6P9oe@redhat.com/
Well, he had a point here^. There's things already outdated in this
sashiko change which we are hearing about after it's merged.
> https://lore.kernel.org/qemu-devel/arpINtziWCbjENeo@intel.com/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-28 23:32 QEMU Sashiko Alistair
` (2 preceding siblings ...)
2026-10-29 12:58 ` Daniel P. Berrangé
@ 2026-10-29 13:35 ` Brian Cain
2026-10-29 14:01 ` Marc-André Lureau
3 siblings, 1 reply; 7+ messages in thread
From: Brian Cain @ 2026-10-29 13:35 UTC (permalink / raw)
To: qemu-devel
On 10/28/2026 6:32 PM, Alistair wrote:
> Hey,
>
> Sashiko just merged initial support for QEMU [1].
>
> For those who don't know, Sashiko is a LLM powered review bot used for
> the Linux kernel. When people send patches to LKML Sashiko reviews the
> patches and responds to the mailing list with any issue that it finds.
>
> Like all LLM tools, it is both useful, but also verbose, prone to
> hallucinations and misses things (like humans do to though). The
> general consensus in the kernel community is that it's a useful and
> valuable tool.
>
> Sashiko is just a Rust application and prompts, it doesn't include a
> LLM and you can use a range of different LLM backends.
>
> Google sponsors the development and runs a Linux instance. So you can
> see the hosted Linux instance here: https://sashiko.dev/ and it uses
> Gemini for the LLM which Google pays for. It seems like there is also a
> GCC one starting up.
>
> The cool thing about Sashiko though is you can run it locally as well,
> so you can use it to test your patches before sending them to LKML, as
> long as you have a LLM backend you can use.
>
> So, now that Sashiko also supports QEMU there are two exciting use
> cases:
>
> 1. Developers can run it locally to review their patches before sending
> them to the list. This can catch issues before sending patches
>
> 2. Maintainers can run an instance to review patches. How you set this
> up depends on the maintainer and how many tokens you have. Pointing it
The one time I tried Sashiko (on kernel patches), it seemed to consume a
mindblowing amount of tokens. Which model(s) do people normally use
with this? Local/open-weight ones or commercial ones? High-end or low-end?
> at the list directly and running it for all patches might be too much,
> but some combination of manually triggering it for certain patches
> seems to work well. The Settings.toml file can be setup based on what
> you want to do.
>
> The hope with this is to save maintainers time as Sashiko can catch
> issues without requiring much time from a maintainer.
>
> QEMU support in Sashiko is very new, so it will take some tweaking to
> improve things, but it is at least a good starting place.
>
> 1:
> https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
>
> Alistair
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: QEMU Sashiko
2026-10-29 13:35 ` Brian Cain
@ 2026-10-29 14:01 ` Marc-André Lureau
0 siblings, 0 replies; 7+ messages in thread
From: Marc-André Lureau @ 2026-10-29 14:01 UTC (permalink / raw)
To: Brian Cain; +Cc: qemu-devel
Hi
On Thu, Oct 29, 2026 at 5:37 PM Brian Cain <brian.cain@oss.qualcomm.com> wrote:
>
>
> On 10/28/2026 6:32 PM, Alistair wrote:
> > Hey,
> >
> > Sashiko just merged initial support for QEMU [1].
> >
> > For those who don't know, Sashiko is a LLM powered review bot used for
> > the Linux kernel. When people send patches to LKML Sashiko reviews the
> > patches and responds to the mailing list with any issue that it finds.
> >
> > Like all LLM tools, it is both useful, but also verbose, prone to
> > hallucinations and misses things (like humans do to though). The
> > general consensus in the kernel community is that it's a useful and
> > valuable tool.
> >
> > Sashiko is just a Rust application and prompts, it doesn't include a
> > LLM and you can use a range of different LLM backends.
> >
> > Google sponsors the development and runs a Linux instance. So you can
> > see the hosted Linux instance here: https://sashiko.dev/ and it uses
> > Gemini for the LLM which Google pays for. It seems like there is also a
> > GCC one starting up.
> >
> > The cool thing about Sashiko though is you can run it locally as well,
> > so you can use it to test your patches before sending them to LKML, as
> > long as you have a LLM backend you can use.
> >
> > So, now that Sashiko also supports QEMU there are two exciting use
> > cases:
> >
> > 1. Developers can run it locally to review their patches before sending
> > them to the list. This can catch issues before sending patches
> >
> > 2. Maintainers can run an instance to review patches. How you set this
> > up depends on the maintainer and how many tokens you have. Pointing it
>
> The one time I tried Sashiko (on kernel patches), it seemed to consume a
> mindblowing amount of tokens. Which model(s) do people normally use
> with this? Local/open-weight ones or commercial ones? High-end or low-end?
>
indeed, I just ran it on 1 patch
(https://patchew.org/QEMU/20261027160606.2668607-2-marcandre.lureau@redhat.com/)
with DeepSeek, 7M tokens after, only to give me a Low report that
isn't even quite accurate. It makes me wonder what it's doing compared
to a simple harness like pi (which would typically consume ~200k
tokens for this sort of review I think).
> > at the list directly and running it for all patches might be too much,
> > but some combination of manually triggering it for certain patches
> > seems to work well. The Settings.toml file can be setup based on what
> > you want to do.
> >
> > The hope with this is to save maintainers time as Sashiko can catch
> > issues without requiring much time from a maintainer.
> >
> > QEMU support in Sashiko is very new, so it will take some tweaking to
> > improve things, but it is at least a good starting place.
> >
> > 1:
> > https://github.com/sashiko-dev/sashiko/commit/e432036bba7ab10d4517385916e6c834d8176f70
> >
> > Alistair
>
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-10-29 14:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-28 23:32 QEMU Sashiko Alistair
2026-10-29 8:06 ` Philippe Mathieu-Daudé
2026-10-29 13:29 ` Fabiano Rosas
2026-10-29 12:50 ` Alex Bennée
2026-10-29 12:58 ` Daniel P. Berrangé
2026-10-29 13:35 ` Brian Cain
2026-10-29 14:01 ` Marc-André Lureau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.