Received: by 10.223.185.116 with SMTP id b49csp5091543wrg; Tue, 27 Feb 2018 07:40:20 -0800 (PST) X-Google-Smtp-Source: AH8x227hWTPMJz2UiUcJeYPjDPmqTA6yN8OSEHO420pGiNG1QNU1A38hXITt+PtrocF+NR473Pcp X-Received: by 10.99.99.66 with SMTP id x63mr11858184pgb.421.1519746020076; Tue, 27 Feb 2018 07:40:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519746020; cv=none; d=google.com; s=arc-20160816; b=aW+R/696XsCRtD7AqCDDvFG90i19E7bPylNur0KDY3YHuDveOOhp0ux7BPbcmTGYbW s2U+4iYLyuEUUkxh/cIzAuoS8i+lqsCZgU0dQTWgG/H9sH0ZnrwpZ2NqCooANHmkpqwY YWd52vQLitE4YDPNWurJPLmBBPU3IqbvT1viAxYgd0FRwLul04cpqkzenW7tRQiM/EtX 9h//zCfKjLVMT9GMV72XILywGGPWBZQf3phs9fiDHOWkjToWg/XRr80X8VwyTWq7w/O7 Kuknt85By/O8xJwtjMOcp1rpn1S3Xt0da/XyRH1WYUcAtCMH7KVPtWvpHSC//aZ2fPqb TTbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=07Z1lkbXh8/SBCz5uC+YaV38iIit6fr1S+vMe8BRJcg=; b=DdCdM5nTKVAYessP8bjmThwoEgLPugjKLs3xsJqGICI5eOK2u6ADTRapeurEkqIpZc 2lizhapmjy7LXm3DnrxyK2FzZANXKcYoY9lgZss/nZLiF8WauHED8k4m1EWJT18bkYjp Xz+4yqOETWu3NKxL0UFJ60dXPtQMDVh/P9zmGONarfMmNwNOU0iRfTRRN/piF7T2ubPg 3JbUsn9NrH0uHNbafJd0SOMWF9rQOBVAtsJAYmV8dFgzHf/OQKLiA2LjzQQECzb8wjKm PbML7SSZ06DSBq+RiA1fzO3GDAIzBjEU/C0BhViHyNvqROkbyOPcKq9kCoYmzGjffi83 xlow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t11-v6si8741677plz.214.2018.02.27.07.40.05; Tue, 27 Feb 2018 07:40:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932153AbeB0PjB (ORCPT + 99 others); Tue, 27 Feb 2018 10:39:01 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:46486 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932115AbeB0PjA (ORCPT ); Tue, 27 Feb 2018 10:39:00 -0500 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eqhHX-0002Lj-FN; Tue, 27 Feb 2018 16:35:07 +0100 Date: Tue, 27 Feb 2018 16:38:59 +0100 (CET) From: Thomas Gleixner To: Reinette Chatre cc: fenghua.yu@intel.com, tony.luck@intel.com, gavin.hindman@intel.com, vikas.shivappa@linux.intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core In-Reply-To: Message-ID: References: <73fb98d2-ce93-0443-b909-fde75908cc1e@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Feb 2018, Thomas Gleixner wrote: > On Mon, 26 Feb 2018, Reinette Chatre wrote: > > Moving to "exclusive" mode it appears that, when enabled for a resource > > group, all domains of all resources are forced to have an "exclusive" > > region associated with this resource group (closid). This is because the > > schemata reflects the hardware settings of all resources and their > > domains and the hardware does not accept a "zero" bitmask. A user thus > > cannot just specify a single region of a particular cache instance as > > "exclusive". Does this match your intention wrt "exclusive"? > > Interesting question. I really did not think about that yet. Actually we could solve that problem similar to the locked one and share most of the functionality: mkdir group echo exclusive > mode echo L3:0 > restrict and for locked: mkdir group echo locksetup > mode echo L2:0 > restrict echo 'L2:0=0xf' > schemata echo locked > mode The 'restrict' file (feel free to come up with a better name) is only available/writeable in exclusive and locksetup mode. In case of exclusive mode it can contain several domains/resources, but in locked mode its only allowed to contain a single domain/resource. A write to schemata for exclusive or locksetup mode will apply the exclusiveness restrictions only to the resources/domains selected in the 'restrict' file. Thanks, tglx