Paolo Bonzini <[email protected]> writes:

> On 1/14/26 10:19, Daniel P. Berrangé wrote:
>> 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.
>
> And indeed their pkgsrc has the same patch that Philippe has now
> submitted for inclusion in qemu.git:
>
> https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_nvmm-all.c.diff?r1=1.10;r2=1.11
>
> ---- target/i386/nvmm/nvmm-all.c.orig 2024-11-20 22:48:05.000000000 +0000
> +--- target/i386/nvmm/nvmm-all.c.orig 2025-08-26 18:32:38.000000000 +0000
>  +++ target/i386/nvmm/nvmm-all.c
> -@@ -1057,7 +1057,11 @@ nvmm_process_section(MemoryRegionSection
> +@@ -984,7 +984,7 @@ nvmm_init_vcpu(CPUState *cpu)
> +         }
> +     }
> +
> +-    qcpu->vcpu_dirty = true;
> ++    cpu->vcpu_dirty = true;
> +     cpu->accel = qcpu;
> +
> +     return 0;
> +@@ -1059,7 +1059,11 @@ nvmm_process_section(MemoryRegionSection
>       unsigned int delta;
>       uintptr_t hva;

That they didn't immediately post the fix upstream is a bit of a
disappointment.  Deep in the weeds, I guess.


Reply via email to