From: Thomas Gleixner <tglx@linutronix.de>
To: Xiaoyao Li <xiaoyao.li@intel.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
hpa@zytor.com, Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
kvm@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Cc: Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Arvind Sankar <nivedita@alum.mit.edu>,
Fenghua Yu <fenghua.yu@intel.com>,
Tony Luck <tony.luck@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Jim Mattson <jmattson@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>
Subject: Re: [PATCH v5 1/9] x86/split_lock: Rework the initialization flow of split lock detection
Date: Mon, 23 Mar 2020 18:02:16 +0100 [thread overview]
Message-ID: <87zhc7ovhj.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200315050517.127446-2-xiaoyao.li@intel.com>
Xiaoyao Li <xiaoyao.li@intel.com> writes:
> Current initialization flow of split lock detection has following issues:
> 1. It assumes the initial value of MSR_TEST_CTRL.SPLIT_LOCK_DETECT to be
> zero. However, it's possible that BIOS/firmware has set it.
Ok.
> 2. X86_FEATURE_SPLIT_LOCK_DETECT flag is unconditionally set even if
> there is a virtualization flaw that FMS indicates the existence while
> it's actually not supported.
>
> 3. Because of #2, KVM cannot rely on X86_FEATURE_SPLIT_LOCK_DETECT flag
> to check verify if feature does exist, so cannot expose it to
> guest.
Sorry this does not make anny sense. KVM is the hypervisor, so it better
can rely on the detect flag. Unless you talk about nested virt and a
broken L1 hypervisor.
> To solve these issues, introducing a new sld_state, "sld_not_exist",
> as
The usual naming convention is sld_not_supported.
> the default value. It will be switched to other value if CORE_CAPABILITIES
> or FMS enumerate split lock detection.
>
> Only when sld_state != sld_not_exist, it goes to initialization flow.
>
> In initialization flow, it explicitly accesses MSR_TEST_CTRL and
> SPLIT_LOCK_DETECT bit to ensure there is no virtualization flaw, i.e.,
> feature split lock detection does supported. In detail,
> 1. sld_off, verify SPLIT_LOCK_DETECT bit can be cleared, and clear it;
That's not what the patch does. It writes with the bit cleared and the
only thing it checks is whether the wrmsrl fails or not. Verification is
something completely different.
> 2. sld_warn, verify SPLIT_LOCK_DETECT bit can be cleared and set,
> and set it;
> 3. sld_fatal, verify SPLIT_LOCK_DETECT bit can be set, and set it;
>
> Only when no MSR aceessing failure, can X86_FEATURE_SPLIT_LOCK_DETECT be
> set. So kvm can use X86_FEATURE_SPLIT_LOCK_DETECT to check the existence
> of feature.
Again, this has nothing to do with KVM.
> * Processors which have self-snooping capability can handle conflicting
> @@ -585,7 +585,7 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
> wrmsrl(MSR_MISC_FEATURES_ENABLES, msr);
> }
>
> -static void split_lock_init(void);
> +static void split_lock_init(struct cpuinfo_x86 *c);
>
> static void init_intel(struct cpuinfo_x86 *c)
> {
> @@ -702,7 +702,8 @@ static void init_intel(struct cpuinfo_x86 *c)
> if (tsx_ctrl_state == TSX_CTRL_DISABLE)
> tsx_disable();
>
> - split_lock_init();
> + if (sld_state != sld_not_exist)
> + split_lock_init(c);
That conditional want's to be in split_lock_init() where it used to be.
> +/*
> + * Use the "safe" versions of rdmsr/wrmsr here because although code
> + * checks CPUID and MSR bits to make sure the TEST_CTRL MSR should
> + * exist, there may be glitches in virtualization that leave a guest
> + * with an incorrect view of real h/w capabilities.
> + * If not msr_broken, then it needn't use "safe" version at runtime.
> + */
> +static void split_lock_init(struct cpuinfo_x86 *c)
> {
> - if (sld_state == sld_off)
> - return;
> + u64 test_ctrl_val;
>
> - if (__sld_msr_set(true))
> - return;
> + if (rdmsrl_safe(MSR_TEST_CTRL, &test_ctrl_val))
> + goto msr_broken;
> +
> + switch (sld_state) {
> + case sld_off:
> + if (wrmsrl_safe(MSR_TEST_CTRL, test_ctrl_val & ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT))
> + goto msr_broken;
> + break;
> + case sld_warn:
> + if (wrmsrl_safe(MSR_TEST_CTRL, test_ctrl_val & ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT))
> + goto msr_broken;
> + fallthrough;
> + case sld_fatal:
> + if (wrmsrl_safe(MSR_TEST_CTRL, test_ctrl_val | MSR_TEST_CTRL_SPLIT_LOCK_DETECT))
> + goto msr_broken;
> + break;
This does not make any sense either. Why doing it any different for warn
and fatal?
> + default:
> + break;
If there is ever a state added, then default will just fall through and
possibly nobody notices because the compiler does not complain.
> + }
> +
> + set_cpu_cap(c, X86_FEATURE_SPLIT_LOCK_DETECT);
> + return;
>
> +msr_broken:
> /*
> * If this is anything other than the boot-cpu, you've done
> * funny things and you get to keep whatever pieces.
> */
> - pr_warn("MSR fail -- disabled\n");
> + pr_warn_once("MSR fail -- disabled\n");
> sld_state = sld_off;
So you run this on every CPU. What's the point? If the hypervisor is so
broken that the MSR works on CPU0 but not on CPU1 then this is probably
the least of your worries.
Thanks,
tglx
next prev parent reply other threads:[~2020-03-23 17:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-15 5:05 [PATCH v5 0/9] x86/split_lock: Add feature " Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 1/9] x86/split_lock: Rework the initialization flow of " Xiaoyao Li
2020-03-21 0:41 ` Luck, Tony
2020-03-23 17:02 ` Thomas Gleixner [this message]
2020-03-23 20:24 ` Thomas Gleixner
2020-03-24 1:10 ` Xiaoyao Li
2020-03-24 10:29 ` Thomas Gleixner
2020-03-25 0:18 ` Xiaoyao Li
2020-03-25 0:52 ` Thomas Gleixner
2020-03-24 11:51 ` Xiaoyao Li
2020-03-24 13:31 ` Thomas Gleixner
2020-03-15 5:05 ` [PATCH v5 2/9] x86/split_lock: Avoid runtime reads of the TEST_CTRL MSR Xiaoyao Li
2020-03-21 0:43 ` Luck, Tony
2020-03-23 17:06 ` Thomas Gleixner
2020-03-23 17:06 ` Thomas Gleixner
2020-03-24 1:16 ` Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 3/9] x86/split_lock: Re-define the kernel param option for split_lock_detect Xiaoyao Li
2020-03-21 0:46 ` Luck, Tony
2020-03-23 17:10 ` Thomas Gleixner
2020-03-24 1:38 ` Xiaoyao Li
2020-03-24 10:40 ` Thomas Gleixner
2020-03-24 18:02 ` Sean Christopherson
2020-03-24 18:42 ` Thomas Gleixner
2020-03-25 0:43 ` Xiaoyao Li
2020-03-25 1:03 ` Thomas Gleixner
2020-03-15 5:05 ` [PATCH v5 4/9] x86/split_lock: Export handle_user_split_lock() Xiaoyao Li
2020-03-21 0:48 ` Luck, Tony
2020-03-15 5:05 ` [PATCH v5 5/9] kvm: x86: Emulate split-lock access as a write Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 6/9] kvm: vmx: Extend VMX's #AC interceptor to handle split lock #AC happens in guest Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 7/9] kvm: x86: Emulate MSR IA32_CORE_CAPABILITIES Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 8/9] kvm: vmx: Enable MSR_TEST_CTRL for intel guest Xiaoyao Li
2020-03-15 5:05 ` [PATCH v5 9/9] x86: vmx: virtualize split lock detection Xiaoyao Li
2020-03-23 2:18 ` [PATCH v5 0/9] x86/split_lock: Add feature " Xiaoyao Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zhc7ovhj.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nivedita@alum.mit.edu \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sean.j.christopherson@intel.com \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®