Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v5 1/9] x86/split_lock: Rework the initialization flow of split lock detection | Date | Tue, 24 Mar 2020 14:31:28 +0100 |
| |
Xiaoyao Li <xiaoyao.li@intel.com> writes: > On 3/24/2020 1:02 AM, Thomas Gleixner wrote: >> 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. >> > > Yeah. It is for the nested virt on a broken L1 hypervisor.
Then please spell it out in the changelog. Changelogs which need crystalballs to decode are pretty useless.
Thanks,
tglx
| |