On Tue, 2026-05-19 at 15:53 +0200, Paolo Bonzini wrote: > On Tue, May 19, 2026 at 3:00 PM David Woodhouse <[email protected]> wrote: > > Or some guest configurations which have only ever been tested under KVM > > could have a bug where they *rely* on the registers not being writable, > > and write values which are inconsistent with the rest of their > > configuration. Which breaks the moment those registers become writable. > > Yeah, just having guests that worked by utter chance - but you still > don't want to break them - is the case that is most likely. Crappy > code that runs only under emulation/virtualization appears with > probability 1 over time. > > Is this likely in this specific case---probably not, honestly. > Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back > then* KVM/Arm was a lot less mature, and people developing for Arm on > vanilla upstream kernels have moved on from Linux 4.19.
It's not really 2018 though. EC2 is still running kernels with that older commit reverted because of the breaking change that it introduced. So the behaviour corresponding to GICD_IIDR.implementation_rev=1 is still current for *millions* of guests. I'm now finding that revert in our tree during a *later* kernel upgrade and trying to eliminate it. And sure, I have given the engineers responsible for that a very hard stare and suggested that they should have fixed it 'properly' in the first place with a patch like the one we're discussing right now. And they're looking at this thread and saying "haha no, if fixing things properly for Arm is this hard then we'll stick with the crappy approach". I do not want them to be right. I don't think any of us want that. > I would still lean towards accepting the code considering the limited > complexity of the addition (in fact I like it more now that it uses > IIDR instead of v2_groups_user_writable, but that's taste). I'm absolutely prepared to have a separate technical discussion about the v2_groups_user_writable thing for GICv2, which is the second part of that series. It seems like the right thing to do, and as far as I can tell, this code *never* worked with QEMU. But I'm not sure who even cares about GICv2 any more. I couldn't find hardware and I had to test the whole thing inside qemu-tcg. But the 'IIDR defaults to 3 but the *behaviour* doesn't match until you explicitly *set* it to 3' thing seemed so *egregiously* wrong to me, that I fixed it anyway.
smime.p7s
Description: S/MIME cryptographic signature
