Re: [PATCH v4 4/4] KVM: SVM: Add Bus Lock Detect support

[Sean Christopherson]

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.