Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 7/29/22 00:13, Sean Christopherson wrote: >> The only flaw in this is if KVM gets handed a CPUID model that enumerates support >> for 2025 (or whenever the next update comes) but not 2022. Hmm, though if Microsoft >> defines each new "version" as a full superset, then even that theoretical bug goes >> away. I'm happy to be optimistic for once and give this a shot. I definitely like >> that it makes it easier to see the deltas between versions. > > Okay, I have queued the series but I still haven't gone through all the > comments. So this will _not_ be in the 5.21 pull request. > > The first patch also needs a bit more thought to figure out the impact > on userspace and whether we can consider syndbg niche enough to not care. (Sorry for delayed replies here, I'm back from vacation now) The first patch is not a requirement for the rest of the series, we can discuss it separately. I, however, think that we can just keep checking HV_FEATURE_DEBUG_MSRS_AVAILABLE in hv_check_msr_access() to be compatible with existing QEMUs and make QEMU expose both HV_FEATURE_DEBUG_MSRS_AVAILABLE and HV_ACCESS_DEBUG_MSRS unconditionally when syndbg feature is enabled as we know that missing HV_ACCESS_DEBUG_MSRS is just a bug. I don't think we actually need to be so picky and support VMMs which want to set 'syndbg without access to it' and 'access to syndbg without syndbg' use-cases. All-or-nothing is likely good enough. -- Vitaly
