On Wed, Aug 21, 2024, Ravi Bangoria wrote: > On 21-Aug-24 11:06 AM, Ravi Bangoria wrote: > >>> @@ -3158,6 +3159,10 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) > >>> if (data & DEBUGCTL_RESERVED_BITS) > >> > >> Not your code, but why does DEBUGCTL_RESERVED_BITS = ~0x3f!?!? That means the > >> introduction of the below check, which is architecturally correct, has the > >> potential to break guests. *sigh* > >> > >> I doubt it will cause a problem, but it's something to look out for. > > This dates back to 2008: https://git.kernel.org/torvalds/c/24e09cbf480a7 > > > > The legacy definition[1] of DEBUGCTL MSR is: > > > > 5:2 PB: performance monitor pin control. Read-write. Reset: 0h. > > This field does not control any hardware. Uh, what? So the CPU provided 4 bits of scratch space? Or is that saying that 5:2 controlled some perfmon stuff on older CPUs, but that Zen deprecated those bits? > > 1 BTF. Read-write. Reset: 0. 1=Enable branch single step. > > 0 LBR. Read-write. Reset: 0. 1=Enable last branch record. > > > > [1]: https://bugzilla.kernel.org/attachment.cgi?id=287389 > > How about adding cpu_feature_enabled() check: That doesn't fix anything, KVM will still break, just on a smaller set of CPUs. The only way to avoid breaking guests is to ignore bits 5:2, though we could quirk that so that userspace can effectively enable what is now the architectural behavior. Though I'm very tempted to just add a prep patch to disallow setting bits 5:2 and see if anyone complains. If they do, then we can add a quirk. And if no one complains, yay.
