Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755345AbaKRQh3 (ORCPT ); Tue, 18 Nov 2014 11:37:29 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:32936 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753865AbaKRQh1 (ORCPT ); Tue, 18 Nov 2014 11:37:27 -0500 MIME-Version: 1.0 In-Reply-To: <20141118154308.GB5238@pd.tnic> References: <1416251225-17721-1-git-send-email-eranian@google.com> <1416251225-17721-14-git-send-email-eranian@google.com> <20141117230232.GC25157@pd.tnic> <20141117235841.GD25157@pd.tnic> <20141118154308.GB5238@pd.tnic> Date: Tue, 18 Nov 2014 17:37:26 +0100 Message-ID: Subject: Re: [PATCH v3 13/13] perf/x86: add syfs entry to disable HT bug workaround From: Stephane Eranian To: Borislav Petkov Cc: Thomas Gleixner , x86-ml , LKML , Peter Zijlstra , "mingo@elte.hu" , "ak@linux.intel.com" , Jiri Olsa , "Liang, Kan" , Maria Dimakopoulou Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 18, 2014 at 4:43 PM, Borislav Petkov wrote: > On Tue, Nov 18, 2014 at 04:29:59PM +0100, Stephane Eranian wrote: >> I am trying to get a better understanding of this scheme. >> >> status: >> - a summary of what is enabled/disabled? >> - With description (as suggested by Boris)? >> - File is readonly >> - is that printing a variable length bitmask? > > Should be the easiest. Maybe extend/add to the X86_BUG() functionality > in arch/x86/include/asm/cpufeature.h which already deals with CPU bugs. > Does it need to bit a bitmask, as opposed to just a bug number (which could be implemented as a bitmask)? >> enable_workaround: >> - provide the bit number (of the workaround) to enable the workaround > > Right, writing the bit number could be part of the description message > above - just so that users know how to control the interface. > writing the bug number.... >> - File is write-only >> >> disable_workaround: >> - provide the bit number (of the workaround) to disable the workaround >> - File is write-only >> >> The split enable/disable is to avoid the read-modify-write issue. >> >> Am I getting this right? >> >> I understand the value of this proposition. But, I feel, it is beyond the scope >> of the patch series to workaround the PMU bug. Initially, we had >> talked about not >> even providing the sysfs file. Now, the series adjusts the workaround >> on boot. The series is restructured so that the sysfs patch is the last >> one and is totally optional. I think we should implement the proposed scheme >> but we should not delay the review and merge of the rest of the patch series >> for this. But I can propose a separate patch series to implement the proposed >> scheme. > > Right, IMHO, we can always add sysfs structure later, when its design is > sane. What we should absolutely avoid is exposing something to userspace > now and then try to hide it/replace it with something else and break > userspace, which, as we all know, is a no-no, punishable by Linus coming > to your house with a bat. > I am okay with this approach. > :-) :-) > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/