On March 24, 2026 7:46:26 AM PDT, Andrew Cooper <[email protected]> wrote: >On 24/03/2026 2:33 pm, H. Peter Anvin wrote: >> On March 24, 2026 7:08:14 AM PDT, Andrew Cooper <[email protected]> >> wrote: >>> On 23/03/2026 8:27 pm, H. Peter Anvin wrote: >>>> On 2026-03-23 12:17, Andrew Cooper wrote: >>>>> This doesn't really test whether FRED is active. It tests whether the >>>>> OS is not providing strict backwards compatibility, and I think will >>>>> malfunction when there's a hypervisor above Linux providing strict >>>>> backwards compatibility. >>>>> >>>> But that applies equally to IRET, no? If the hypervisor clobbers the >>>> segment >>>> selector like IRET would in the interest of compatibility then you have the >>>> same issue. >>> I suppose. I for one don't care to provide that level of compatibility. >>> >>> But for SYSCALL, what are Linux's plans for CRIU or RR ? I had to fix >>> SYSCALL legacy behaviour in Xen for the following case: >>> >>> * PV guest issues SYSCALL on FRED system. %rcx/%r11 not clobbered >>> * Migrate to a non-FRED system >>> * Xen uses a real SYSRET instruction to resume execution >>> >>> >>> Here, the guest continues executing at whichever dead variable is in %rcx. >>> >>> CRIU/RR won't be exactly the same, but will suffer the same class of >>> problem when moving between FRED and non-FRED systems. >>> >>> ~Andrew >> "Doctor, it hurts when I PV?" > >I'm asking straight up, what is Linux doing to fix this same issue for >CRIU/RR? > >~Andrew > >P.S. It's rhetorical, seeing as it's taken between Linux 6.9 and now (2 >whole years) for anyone to even run the x86 selftests on a FRED system.
That's not true, and in fact *this exact bug was fixed once already*; apparently someone "fixed the fix?" I'm well and truly confused by it.
