QEMU Sashiko

QEMU Sashiko

[Alistair]

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

Re: QEMU Sashiko

[Philippe Mathieu-Daudé]

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/

Re: QEMU Sashiko

[Fabiano Rosas]

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/

Re: QEMU Sashiko

[Alex Bennée]

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

Re: QEMU Sashiko

[Alistair]

On Thu, 2026-10-29 at 12:50 +0000, Alex Bennée wrote:
> 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  

Oh cool!

> 
> > 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?

For a project in general, that's tricky.

I have had luck reviewing patches I'm interested in and haven't hit any
cost limits yet. A small-ish local LLM also works which is mostly free
at that point.

> 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.

I suspect so as well.

It looks like Google is now running Linux and GCC reviews, so maybe
QEMU is next?

> 
> > 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. 

Yeah, but there are cheaper cloud models that are almost as good, or
local models that are probably good enough.

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

That's true.

The Kernel Sashiko sends the results to the original contributor (and
some others), so it puts the burden on the contributor to decipher the
text.

That obviously has a cost, but doesn't add much to a maintainer.

> 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.

Exactly!

From my experience with Linux and Sashiko I don't even think the latest
and greatest frontier models provide useful input on the design of a
patch.

It's good at catching bugs and issues that humans aren't good at.
Saving maintainers time there, while leaving them to think about the
actual design.

I don't have any hard numbers, but I do suspect a local model could
work fine for this

> 
> 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.

Exactly! That's a big part of my hope.

Alistair

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

Re: QEMU Sashiko

[Daniel P. Berrangé]

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 :|

Re: QEMU Sashiko

[Alistair]

On Thu, 2026-10-29 at 12:58 +0000, Daniel P. Berrangé wrote:
> 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 ?

Sashiko has access to the QEMU tree. Otherwise Sashiko won't go out
onto the internet and access things.

So in theory we can point it at docs or anything else in the QEMU repo.

> 
> 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.

That should generally be workable, if we have those guidelines

Alistair

> 
> 
> With regards,
> Daniel

Re: QEMU Sashiko

[Brian Cain]

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

Re: QEMU Sashiko

[Marc-André Lureau]

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