[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e708f6d2-8f96-903c-0bce-2eeecc4a237d@intel.com>
Date: Tue, 24 Mar 2020 09:38:30 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
hpa@...or.com, Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org
Cc: Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Arvind Sankar <nivedita@...m.mit.edu>,
Fenghua Yu <fenghua.yu@...el.com>,
Tony Luck <tony.luck@...el.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Jim Mattson <jmattson@...gle.com>
Subject: Re: [PATCH v5 3/9] x86/split_lock: Re-define the kernel param option
for split_lock_detect
On 3/24/2020 1:10 AM, Thomas Gleixner wrote:
> Xiaoyao Li <xiaoyao.li@...el.com> writes:
>
>> Change sld_off to sld_disable, which means disabling feature split lock
>> detection and it cannot be used in kernel nor can kvm expose it guest.
>> Of course, the X86_FEATURE_SPLIT_LOCK_DETECT is not set.
>>
>> Add a new optioin sld_kvm_only, which means kernel turns split lock
>> detection off, but kvm can expose it to guest.
>
> What's the point of this? If the host is not clean, then you better fix
> the host first before trying to expose it to guests.
It's not about whether or not host is clean. It's for the cases that
users just don't want it enabled on host, to not break the applications
or drivers that do have split lock issue.
> Thanks,
>
> tglx
>
Powered by blists - more mailing lists