On Tue, 2026-05-19 at 14:13 +0200, Paolo Bonzini wrote: > I admit that my knowledge of Arm is really limited, and I do not > understand which IIDR values have architecturally allowed behaviors > and which (if any) were made up by KVM; but even if I cannot honestly > remark on the code or even the approach, a compatibility knob is the > right thing to have. That's a userspace API design matter, not an Arm > or GIC matter.
To be clear: the "IID" in IIDR is "implementer identification"; the implementer in this case being KVM. The revision field in the IIDR literally *is* the compatibility knob. The values are indeed 'made up by KVM', and have been correctly bumped from 1 to 2 to 3 as guest-visible behaviour has changed. The only problem is that there's no way to set it *back* to 1 again, on a newer kernel (which defaults to 3). We can only set it to 2 or 3. The patch which is causing all this fuss is little more than a one- liner which allows userspace to set it to 1 again, and a second line to actually *honour* the corresponding behaviour that certain registers aren't writable. This is the only way to retain that historical behaviour so that we don't have to change it underneath running guests on a kernel upgrade (or worse, rip the new behaviour *away* from newly-launched guests, if we have to roll back to the old kernel after launching on the new one). > I will certainly take this patch, but I won't override Marc. However > I'd like to better understand his point of view, because right now I > just don't get it. Indeed. Like you, I just don't get it. I cannot see any reason *not* to take the fix, and I am *trying* (with limited success) to limit the expression of my frustration to the specific technical issue at hand. Marc, I have a huge amount of respect for you, and I'm painfully aware that I risk burning bridges here by pressing the issue. But on this specific topic I respectfully believe that you have made the wrong decision, and I beg you to reconsider. We *need* to be able to upgrade without changing behaviour for guests. Even if the old behaviour was "wrong" according to the architecture specification.
smime.p7s
Description: S/MIME cryptographic signature
