[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <372d5a95-bce5-4c5c-8c74-6b4cc5ab6943@amd.com>
Date: Wed, 21 Aug 2024 11:06:41 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, pbonzini@...hat.com, thomas.lendacky@....com,
jmattson@...gle.com, hpa@...or.com, rmk+kernel@...linux.org.uk,
peterz@...radead.org, james.morse@....com, lukas.bulwahn@...il.com,
arjan@...ux.intel.com, j.granados@...sung.com, sibs@...natelecom.cn,
nik.borisov@...e.com, michael.roth@....com, nikunj.dadhania@....com,
babu.moger@....com, x86@...nel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, santosh.shukla@....com,
ananth.narayan@....com, sandipan.das@....com, manali.shukla@....com,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH v4 4/4] KVM: SVM: Add Bus Lock Detect support
>> @@ -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.
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
Thanks,
Ravi
Powered by blists - more mailing lists