On Wed, Jan 14, 2026 at 08:38:26AM +0100, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <[email protected]> writes:
>
> > On 13/1/26 20:32, Thomas Huth wrote:
> >> On 04/07/2025 12.14, Philippe Mathieu-Daudé wrote:
> >>> No need for accel-specific @dirty field when we have
> >>> a generic one in CPUState.
> >>>
> >>> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
> >>> Reviewed-by: Richard Henderson <[email protected]>
> >>> Reviewed-by: Xiaoyao Li <[email protected]>
> >>> Reviewed-by: Zhao Liu <[email protected]>
> >>> Message-Id: <[email protected]>
> >>> ---
> >>> target/i386/nvmm/nvmm-all.c | 21 ++++++++++-----------
> >>> 1 file changed, 10 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/target/i386/nvmm/nvmm-all.c b/target/i386/nvmm/nvmm-all.c
> >>> index f1c6120ccf1..aea61a6fd2a 100644
> >>> --- a/target/i386/nvmm/nvmm-all.c
> >>> +++ b/target/i386/nvmm/nvmm-all.c
> >> ...
> >>> @@ -982,7 +981,7 @@ nvmm_init_vcpu(CPUState *cpu)
> >>> }
> >>> }
> >>> - qcpu->dirty = true;
> >>> + qcpu->vcpu_dirty = true;
> >>> cpu->accel = qcpu;
> >>> return 0;
> >> FYI, this does not seem to compile:
> >> ../src/target/i386/nvmm/nvmm-all.c: In function 'nvmm_init_vcpu':
> >> ../src/target/i386/nvmm/nvmm-all.c:988:9: error: 'AccelCPUState' has no
> >> member named 'vcpu_dirty'
> >> 988 | qcpu->vcpu_dirty = true;
> >> | ^~
> >
> > s/qcpu/cpu/
> >
> >> Is anybody checking the netbsd builds at all?
> >
> > 3 reviewers and 6 months later.
>
> I have good news! Because this does not compile since 10.1, and we're
> already in the 11.0 cycle, we can rip it out immediately without doing
> the deprecation dance.
>
> > Should we add a policy for bitrotting untested code?
>
> What policy do you have in mind?
Implicitly I consider the policy to effectively be
(1) Platforms untested by GitLab CI are not guaranteed to work at
any time, including in formal releases.
(2) No contributors/maintainers are obligated to investigate or
fix breakage in untested platforms
(3) Those whom care about the platform are expected to perform
manual testing and contribute fixes as required.
This doesn't imply we should automatically rip it out, but if we see
no evidence of (3) for a prolonged period of time, and no sign of it
being used downstream in any way, it is worth considering the cost /
benefit.
In the case of NetBSD something must be working to some extent since
it appears that 10.1.0 QEMU is present in the pkg repos:
https://pkgsrc.se/emulators/qemu
so that argues against ripping stuff out even if we notice breakage.
> >> (I'm currently trying to update test/vm/netbsd to version 10.1, that's how
> >> I noticed it)
> >> Thomas
> >>
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
