On 6/23/2026 1:10 PM, Pierrick Bouvier wrote:
On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
On 6/23/2026 6:58 AM, Peter Maydell wrote:
On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
<[email protected]> wrote:
On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
On 22/6/26 22:52, Pierrick Bouvier wrote:
On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
Hello,
This series looks scary but it's mostly trivial and mechanical work.
It is yet another attempt at fixing --disable-tcg. We have a recent
work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
Phil's work didn't get merged and it's now too hard to rebase and
revive, the most recent attempt got misled into the 'what is
common code
between TCG and KVM' dungeon.
It seems like series does not apply on top of master, would that be
possible to rebase it?
For some reason the RISC-V series are handled distinctly than the
rest of QEMU, Alistair queues work on his repository and developers
are custome to base their series on top of it (otherwise Alistair
can not apply them on his tree and asks for reposts), see the
riscv-to-apply.next branch on https://github.com/alistair23/qemu.
Unfortunately, it makes it hard to run any kind of automated testing,
especially for series like this that target specific configs.
Don't we have ways of saying in the commit message "these patches
applies
on top of these other patches" and then the tooling would deal with it?
I remember patchew doing stuff like that with that "Based-on:
<message-id>"
tag.
Yes, Based-on: is our convention for marking "this patchset needs some
other one to be applied first". But that should be the exception rather
than a common case -- if patchsets regularly need to be based on
something other than head-of-git, this is I think a sign that
maintainers are not sending out pull requests frequently enough.
I would prefer it if QEMU didn't develop kernel-style "subsystems
have their own particular workflows" fragmentation -- I don't
think we're big enough or that sub-parts of QEMU are sufficiently
well separated for it to work out well.
I agree that rebasing things on master is better than rebasing it on the
maintainer's tree. And we could make a better job at informing
developers that
submitting a patch for qemu-riscv, vfio or any particular subtree, means
that
the patch should be based on a maintainer tree X.
The thing is that sending patches on master only works if master is
always up
to date, and that's not feasible with our current style of merging PRs.
This
series we're commenting on is an example: it doesn't apply to master
because
there are pre-approved RISC-V patches in the maintainer's tree from 2
days ago
(also my patches, I might add) that caused conflicts that I wasn't aware
that
would happen. This conflict would have to be dealt with at some point
by myself
or the maintainer, and it's not like 2 days is too much time without a PR.
We can argue "this is an exception that doesn't happen that often, we
should
stick with using master as a base", and to a certain extend that's
true. But
then this sort of conflict happens again, then again, then again, it
comes to
a point where it's easier to tell developers to use the maintainer's
tree instead
of master.
Maybe I'm downplaying the problem because I've been sending stuff based
on the
maintainer's tree since forever and got used to it. IMO, unless we
decide to be
like libvirt and create the "committer" role to allow trustworthy devs
to push
stuff to master after acks, making it more feasible to expect master to
be up to
date, I'm afraid we're closer to a kernel-style workflow. For better or
worse.
Thanks,
Daniel
thanks
-- PMM
In this very specific case, where base patches are needed, maybe it
would be better to make the required commits appear in this series, and
mention in cover letter that patches 1-N are just coming from another
series and are already reviewed/approved. IMHO it doesn't hurt, and
reviewers are free to skip commits already reviewed.
That's fair enough but I wonder if that won't scare people away with
even bigger series :D in this case here I would need to either send all
the queued patches, making the series go to 40+, or I would need to triage
which patches from the queue creates a conflict with this work and send
only those.
Now, as for qemu-ci ... How farfetched it is to make it read a specific tag
in the cover-letter, e.g. "branch-id", that can point to a gitlab/github
repo with the patches, and use that code base instead of applying the
patches to the master branch? Then for the next version of this work
I could do
"branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2";
and the tool would still work. If there's no "branch-id" then it assumes
that the patches are to be applied on master.
And yeah, in an ideal world the problem goes away if we just do more PRs and
strive to keep 'master' updated. I'm just thinking out loud about possible
alternatives until we reach that point.
Cheers,
Daniel
Or, a solution I'm not fond of but I ended up adopting most of the time,
just wait for required patches to be merged on master before posting the
series, and work on something else meanwhile.
Ideally, yes, it would be better if maintainers could send PR more
frequently to avoid creating those intermediate staging trees. The
faster we merge, the less conflicts we'll have.
Regards,
Pierrick
