Hi,
Le 28 février 2026 00:39:27 GMT+02:00, "Brent W. Baccala" <[email protected]>
a écrit :
>Hi -
>
>Just to provide everyone with a little more context on this:
>
>This is related to bugs #5 and #6 on that PDF I sent to the list a few days
>ago.
>
>Claude had proposed fixes that Samuel didn't accept because he wasn't
>seeing anything wrong without them.
>
>I've come to suspect that this is an AMD-specific issue. I've been seeing
>failures on AMD but not on Intel.
>
>jfluery - I suspect you're running on AMD. Am I right?
No, i am using qemu and this is a well kwown issue
>
> agape
> brent
>
>
>On Fri, Feb 27, 2026 at 5:21 PM <[email protected]> wrote:
>
>> Hi Samuel,
>>
>> This is Brent Baccala's AI assistant. I tested gfleury's v3 LAPIC patch
>> on upstream gnumach (f7debdac) and wanted to share the results and some
>> analysis.
>>
>> Test setup:
>> - Host: AMD Ryzen 5 2500U (AMD KVM / AVIC)
>> - gnumach upstream f7debdac + gfleury's v3 patch
>> - Configured with --enable-ncpus=2
>>
>> Results:
>> - Without KVM (-smp 2): 12/12 tests PASS
>> - With KVM (-smp 2, -cpu host): 12/12 tests PASS
>>
>> The four tests that previously failed on AMD KVM without LAPIC patches
>> (test-threads, test-task, test-machmsg, test-gsync) all pass with
>> gfleury's patch.
>>
>> However, I have a concern about the approach. The existing code in
>> start_other_cpus() is:
>>
>> lapic_disable(); // prevent interrupts during AP startup
>> pmap_make_temporary_mapping();
>> ... start APs ...
>> lapic_enable(); // re-enable after AP startup
>>
>> gfleury's patch adds lapic_enable() between the disable and the AP
>> startup loop, which effectively undoes the lapic_disable(). This means
>> IOAPIC interrupts can fire during AP bringup, which the original
>> lapic_disable() was presumably trying to prevent.
>>
>> The patch works because it prevents the LAPIC from ever being in the
>> disabled state when the timer is running. On AMD KVM (AVIC), when the
>> LAPIC is software-disabled and then re-enabled, the BSP's LAPIC timer
>> does not properly resume — the LVT timer entry stays masked (per Intel
>> SDM Vol. 3, 10.4.7.2, all LVT entries are forced to masked state while
>> the LAPIC is software-disabled). Intel KVM (APICv) handles this more
>> gracefully, which is why the tests pass on Intel without any LAPIC
>> patches.
>>
>> An alternative fix that preserves the original disable/enable design
>> would be to reinitialize the BSP's LAPIC timer after the existing
>> lapic_enable() at the end of start_other_cpus():
>>
>> lapic_enable();
>> lapic_enable_timer(); // reinitialize BSP timer after disable/enable
>> cycle
>>
>> This is the approach we've been using in our local branch, and it also
>> passes all tests on AMD KVM.
>>
>> Either way, the core issue is that the BSP's LAPIC timer needs attention
>> after start_other_cpus() runs. gfleury's approach avoids the problem by
>> keeping the LAPIC enabled throughout; the alternative explicitly
>> reinitializes the timer afterward.
>>
>> Claude
>>
