From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9FD0C433EF for ; Fri, 13 May 2022 09:27:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 358096B0073; Fri, 13 May 2022 05:27:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3091D6B0075; Fri, 13 May 2022 05:27:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6506B0078; Fri, 13 May 2022 05:27:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 10B586B0073 for ; Fri, 13 May 2022 05:27:03 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D55DBB64 for ; Fri, 13 May 2022 09:27:02 +0000 (UTC) X-FDA: 79460190684.11.8982047 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf24.hostedemail.com (Postfix) with ESMTP id 8482C1800DD for ; Fri, 13 May 2022 09:26:53 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652434020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Php+ZJ83A5DPq79iQSx2r7Rgggl0xBFSJkKdjRMuVAM=; b=n2+cKQf7QtlEHZ7/6xhAPT21fnqoei1jVHC0efwy9KrOEHxm5OdXniXQw50LIbgdP/Dand APAQ89v6fLyYpX8/V2/Gy2C6g/ucOPN9VgDCh52bk86cuNYe9Zanbs9lK3dQLVdUxbX78J VeMuaPIiA54X8qwtVZ7on71eG9tNSjUIHNG++AwSRh2YtcF4y/9u4pgzC8oJlY5HRDsgkP XtDwGrBbU7w9Ia+jwyOqW/EoiPZMWG+vXUBuvgrkL02inXUULsy0r+eJFzbyCRdafAaWCg 55xL/+MbIoOvNozNrh8SBX82QoOISv888VkvPcHVn5TrExo/mBZmIma8NZwFAA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652434020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Php+ZJ83A5DPq79iQSx2r7Rgggl0xBFSJkKdjRMuVAM=; b=qLTgxfdko9IOD+Xt5izjeOXBMTbSyXbQH8RnIupuq5f+bqLQWqrtMgG6AsGgk021/VxvDJ ETem9/Ks5+HTOLAA== To: Catalin Marinas Cc: Dave Hansen , "H.J. Lu" , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , the arch/x86 maintainers , Alexander Potapenko , Dmitry Vyukov , Andi Kleen , Rick Edgecombe , Linux-MM , LKML Subject: Re: [RFCv2 00/10] Linear Address Masking enabling In-Reply-To: References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> <87o802tjd7.ffs@tglx> <67aef839-0757-37b1-a42d-154c0116cbf5@intel.com> <878rr6te6b.ffs@tglx> Date: Fri, 13 May 2022 11:26:59 +0200 Message-ID: <8735hdu6jg.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8482C1800DD X-Stat-Signature: k9zrq76ikff3n7xm5b9cthuduisgi351 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=n2+cKQf7; dkim=pass header.d=linutronix.de header.s=2020e header.b=qLTgxfdk; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf24.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-Rspam-User: X-HE-Tag: 1652434013-685463 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 13 2022 at 10:14, Catalin Marinas wrote: > On Fri, May 13, 2022 at 03:27:24AM +0200, Thomas Gleixner wrote: >> On Thu, May 12 2022 at 17:46, Dave Hansen wrote: >> > On 5/12/22 17:08, H.J. Lu wrote: >> > If I had to take a shot at this today, I think I'd opt for: >> > >> > mask = sys_enable_masking(bits=6, flags=FUZZY_NR_BITS); >> > >> > although I'm not super confident about the "fuzzy" flag. I also don't >> > think I'd totally hate the "blind" interface where the kernel just gets >> > to pick unilaterally and takes zero input from userspace. >> >> That's the only sane choice and you can make it simple for userspace: >> >> ret = prctl(GET_XXX_MASK, &mask); >> >> and then let it decide based on @ret and @mask whether to use it or not. > > Getting the mask would work for arm64 as well (it's always 0xffUL << 56, > top-byte-ignore). Setting the mask from user space won't be of any use > to us, it's baked in hardware. Sure. > Dave indeed mentioned passing a mask to allow a more flexible control > but, as already mentioned in the old thread, for arm64 the feature was > already on, so it didn't make much sense, it seemed more like > over-engineering. Had we known that Intel is pursing something similar, > maybe we'd have designed the interface differently (we didn't get the > hint). Fair enough > Intel's LAM has more flexibility but I don't see the arm64 TBI getting > in the way. Just don't use it as an example because they evolved in > different ways. I'm happy for arm64 to adopt a more flexible interface > while keeping the current one around for backwards compatibility). But > on arm64 we can't control the masking, not even disable it per process > since it has always been on. That's fine. The point is that we want uniform interfaces for the same functionality. It's obviously hardware specific which subset of the interface is supported. >> I'm so tired of this short sighted 'cram my feature in' approach of >> _all_ involved parties. > > Unfortunately it happens occasionally, especially when developers can't > disclose that their companies work on similar features (resctrl is a > good example where arm64 would have benefited from a more generic > approach but at the time MPAM was not public). Yeah. It's a constant pain. Thanks, tglx