From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S941438AbcIHNTq (ORCPT <rfc822;w@1wt.eu>);
        Thu, 8 Sep 2016 09:19:46 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:44263 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932307AbcIHNTp (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 8 Sep 2016 09:19:45 -0400
Date: Thu, 8 Sep 2016 15:17:00 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Fenghua Yu <fenghua.yu@intel.com>
cc: "H. Peter Anvin" <h.peter.anvin@intel.com>,
        Ingo Molnar <mingo@elte.hu>, Tony Luck <tony.luck@intel.com>,
        Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
        Borislav Petkov <bp@suse.de>, Stephane Eranian <eranian@google.com>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        David Carrillo-Cisneros <davidcc@google.com>, Shaohua Li <shli@fb.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        Sai Prakhya <sai.praneeth.prakhya@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation
 detection
In-Reply-To: <1473328647-33116-8-git-send-email-fenghua.yu@intel.com>
Message-ID: <alpine.DEB.2.20.1609081509560.5647@nanos>
References: <1473328647-33116-1-git-send-email-fenghua.yu@intel.com> <1473328647-33116-8-git-send-email-fenghua.yu@intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 8 Sep 2016, Fenghua Yu wrote:
> +			cpuid_count(0x00000010, 1, &eax, &ebx, &ecx, &edx);
> +			c->x86_l3_max_closid = edx + 1;
> +			c->x86_l3_max_cbm_len = eax + 1;

According to the SDM:

EAX     Bits  4:0:  Length of the capacity bit mask for the corresponding ResID.
        Bits 31:05: Reserved

EDX	Bits 15:0:  Highest COS number supported for this ResID.
	Bits 31:16: Reserved

So why are we assuming that bits 31-5 of EAX and 16-31 of EDX are going to
be zero forever and if not that they are just extending the existing bits?
If that's the case then we don't need to mask out the upper bits, but the
code wants a proper comment about this.

Thanks,

	tglx