lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Oct 2016 11:04:07 -0700 From: "Luck, Tony" <tony.luck@...el.com> To: Nilay Vaish <nilayvaish@...il.com> Cc: Fenghua Yu <fenghua.yu@...el.com>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <h.peter.anvin@...el.com>, Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>, Stephane Eranian <eranian@...gle.com>, Borislav Petkov <bp@...e.de>, Dave Hansen <dave.hansen@...el.com>, Shaohua Li <shli@...com>, David Carrillo-Cisneros <davidcc@...gle.com>, Ravi V Shankar <ravi.v.shankar@...el.com>, Sai Prakhya <sai.praneeth.prakhya@...el.com>, Vikas Shivappa <vikas.shivappa@...ux.intel.com>, linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org> Subject: Re: [PATCH v3 05/18] Documentation, x86: Documentation for Intel resource allocation user interface On Tue, Oct 11, 2016 at 12:07:33PM -0500, Nilay Vaish wrote: > On 10 October 2016 at 12:19, Luck, Tony <tony.luck@...el.com> wrote: > > The next resource coming will have values that are simple ranges {0 .. max} > > > > Regarding addition of more resources, I was wondering if one common > definition of struct rdt_resource to be used for each resource the way > to take. As you point out, L2 caches will not support CDP, but cdp > would be part of the variable describing L2 cache. Should we have > separate structs for each resource? Yes and no. CDP is currently the only real difference between L2 and L3, and the current code will just never set the @cdp_capable field to true. It seems less of a burdern to carry two extra "bool" fields in the resource that won't use them, than to architect some complex scheme that allows different resources to have different structures. The structure essentially has to be the same for each resource so that we can do: for_each_rdt_resource(r) { something() } all over the code (from bringing cpus online and taking them off again to deciding which lines to print in the schemata file). There are over a dozen places where this happens, and it is the key to making it easy to add support for new resources. However, I expect the structure to morph as new resources require a different "something()". E.g. validating a new resource limit value in the schemata file. Right now the function that does that has the weird rules about consecutive bits in the bitmask hard wired into it. When we get a resource that allows a simple range, we'll want a simpler function. Spoiler: that resource also expects "0" as the default value which doesn't restrict accesss, bigger numbers limiting access more. So we may also want an "initial_value", or "default_value" field so the discovery and cleanup code can set the per resource MSR array correctly. So we'll add some per-resource flags. Perhaps the validation function will be a function pointer in the structure. If there are many such differences, we might end up with all the common fields at the front of the structure, and a union of structures with the per resource type bits. But we can make that call as we add new resources. -Tony
Powered by blists - more mailing lists