Re: [PATCH v4 4/4] KVM: SVM: Add Bus Lock Detect support
From: Sean Christopherson
Date: Mon Aug 26 2024 - 14:31:47 EST
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.