[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1609081509560.5647@nanos>
Date: Thu, 8 Sep 2016 15:17:00 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Fenghua Yu <fenghua.yu@...el.com>
cc: "H. Peter Anvin" <h.peter.anvin@...el.com>,
Ingo Molnar <mingo@...e.hu>, Tony Luck <tony.luck@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Tejun Heo <tj@...nel.org>, Borislav Petkov <bp@...e.de>,
Stephane Eranian <eranian@...gle.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
David Carrillo-Cisneros <davidcc@...gle.com>,
Shaohua Li <shli@...com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
Sai Prakhya <sai.praneeth.prakhya@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation
detection
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
Powered by blists - more mailing lists