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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZwV_B-4gz9tUaF67@agluck-desk3.sc.intel.com>
Date: Tue, 8 Oct 2024 11:50:47 -0700
From: Tony Luck <tony.luck@...el.com>
To: James Morse <james.morse@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
	Fenghua Yu <fenghua.yu@...el.com>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	H Peter Anvin <hpa@...or.com>, Babu Moger <Babu.Moger@....com>,
	shameerali.kolothum.thodi@...wei.com,
	D Scott Phillips OS <scott@...amperecomputing.com>,
	carl@...amperecomputing.com, lcherian@...vell.com,
	bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
	baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
	Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
	dfustini@...libre.com, amitsinght@...vell.com,
	David Hildenbrand <david@...hat.com>,
	Rex Nie <rex.nie@...uarmicro.com>,
	Dave Martin <dave.martin@....com>,
	Shaopeng Tan <tan.shaopeng@...fujitsu.com>
Subject: Re: [PATCH v5 30/40] x86/resctrl: Describe resctrl's bitmap size
 assumptions

On Fri, Oct 04, 2024 at 06:03:37PM +0000, James Morse wrote:
> resctrl operates on configuration bitmaps and a bitmap of allocated
> CLOSID, both are stored in a u32.
> 
> MPAM supports configuration/portion bitmaps and PARTIDs larger
> than will fit in a u32.
> 
> Add some preprocessor values that make it clear why MPAM clamps
> some of these values. This will make it easier to find code related
> to these values if this resctrl behaviour ever changes.

...

> +#define RESCTRL_MAX_CLOSID		32

Do you really need to do this? Intel x86 architecture allows for more than
32 CLOSIDs, it's just expensive in h/w to get past 16 ... so I picked
that trivial bitmap allocator in ages past. But if ARM can have more,
then why would you need to clamp the value? File system code could ask
architecture code to allocate a CLOSID. On x86 that will fail when there
are no more CLOSIDs, so filesystem will fail the mkdir(2).

Or, since you put closid_alloc() into the filesystem code you could
change the closid_free_map to u64.

If you really do want to have this #define ... maybe you should use it
in place of the hard coded 32 here:

static void closid_init(void)
{
        struct resctrl_schema *s;
        u32 rdt_min_closid = 32;
}


> +#define RESCTRL_MAX_CBM		32

Intel x86 could plausibly expand the cache bitmap size (the MSRs
that store them currenly have bits 63:32 reserved, but that could be
changed). The only 32-bit limits are the CPUID field that enumerates
CBM_LEN and the CPUID field that enumerates the shared bitmap. The
length has space for expansion, the share bitfiled does not. So if
Intel did go to more than 32-bits we'd be stuck making sure any shared
bits were in the lower 32-bits.

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ