On Mon, Feb 28, 2022, Oliver Upton wrote: > On Mon, Feb 28, 2022 at 04:33:57PM +0000, Sean Christopherson wrote: > > On Sat, Feb 26, 2022, Oliver Upton wrote: > > > KVM_CAP_DISABLE_QUIRKS is irrevocably broken. The capability does not > > > advertise the set of quirks which may be disabled to userspace, so it is > > > impossible to predict the behavior of KVM. Worse yet, > > > KVM_CAP_DISABLE_QUIRKS will tolerate any value for cap->args[0], meaning > > > it fails to reject attempts to set invalid quirk bits. > > > > FWIW, we do have a way out without adding another capability. The 'flags' field > > is enforced for all capabilities, we could use a bit there to add "v2" functionality. > > Userspace can assume KVM_QUIRK_ENFORCE_QUIRKS is allowed if the return from probing > > the capability is >1. > > > > It's gross and forced, just an idea if we want to avoid yet another cap. > > I had considered this before sending out v1, but was concerned if a > userspace didn't correctly handle a return value >1 from > KVM_CHECK_EXTENSION. Ah, right, userspace could theoretically check "== 1". Blech. > Turns out, I can't even find any evidence of the KVM_CAP_DISABLE_QUIRKS used > by userspace. I spot checked QEMU, kvmtool, > and a couple of the rusty ones. > > The only other thing that comes to mind is it's a bit gross for userspace > to do a graceful fallback if KVM_QUIRK_ENFORCE_QUIRKS isn't valid, since > most userspace would just error out on -EINVAL. At least with a new cap > userspace could follow a somewhat standardized way to discover if the > kernel supports enforced quirks. Yeah, a QUIRKS2 is probably easier for everyone.
