Re: [PATCH v4 4/7] fs,x86/resctrl: Add architecture hooks for every mount/unmount

["Luck, Tony" <tony.luck@intel.com>]

On Thu, Apr 23, 2026 at 04:54:07PM -0700, Reinette Chatre wrote:
> Hi Tony,
> 
> On 4/23/26 3:29 PM, Luck, Tony wrote:
> > On Wed, Apr 22, 2026 at 03:10:59PM -0700, Reinette Chatre wrote:
> >> Hi Tony,
> >>
> >> On 4/22/26 2:59 PM, Luck, Tony wrote:
> >>>>> Seems OK. But to make sure that events are accessible, architecture will
> >>>>> now have to "hold" the pmt_telemetry module regardless of whether
> >>>>> resctrl file system is mounted.
> >>>>
> >>>> Could you please elaborate why this is required? if I understand correctly the
> >>>> "hold" on the pmt_telemetry module will be done by itself between the
> >>>> intel_pmt_get_regions_by_feature() and intel_pmt_put_feature_group() calls.
> >>>
> >>> If architecture code runs completely asynchronously to resctrl mount/unmount
> >>
> >> Since there is shared state that is managed via existing locks I do not see
> >> architecture running completely asynchronously to resctrl mount/unmount.
> > 
> > I think I now have a solution without any new locks in the file system
> > layer (just a call to resctrl_arch_pre_mount() on every mount and a
> > call to resctrl_arch_unmount() if the mount fails, and on unmount).
> > 
> > Testing in progress. Cleanup to follow before posting.
> 
> Thank you.
> 
> >>
> >>> when would it be safe to call intel_pmt_put_feature_group()?
> >>
> >> I think I am missing something here since I have been assuming all along
> >> that intel_pmt_put_feature_group() is and will continue to be called from the
> >> new unmount handler.
> > 
> > Correct.
> >>
> >> Reinette
> > 
> > I'm looking at a more aggressive change to the Kconfig options.
> > 
> > Linus complained[1] that the biggest pain point for new people is getting
> > the kernel configured. Extra CONFIG options was his prime focus.
> 
> Thank you for pointing this out.
> 
> > 
> > So I'm looking at removing CONFIG_X86_CPU_RESCTRL_INTEL_AET completely and
> > just making intel_aet.c included with CONFIG_X86_CPU_RESCTRL.
> 
> Sounds reasonable but how the final dependencies would look like is not obvious to me.
> Consider for example this removal happening with today's Kconfig that may force
> a kernel that will run on AMD/Hygon to be built with INTEL_PMT_TELEMETRY/INTEL_TPMI.
> Something like this does not look right.
> 
> > It does mean the resctrl will depend on X86_64, killing 32-bit support.
> > That was discussed before and decision deferred. But there's other 64-bit MMIO
> > stuff in the pipeline that means we have to make this change sooner or later.
> > 
> > Thoughts on unconditional inclusion and on removing 32-bit support?
> 
> I believe we already have a clear answer on 32-bit support for resctrl on *x86*
> from Thomas https://lore.kernel.org/lkml/87jzm3jckw.ffs@tglx/ and
> Babu https://lore.kernel.org/lkml/162f5113-4eb6-dcea-f034-c81b9dc021b6@amd.com/

Good.

> Whether this can be extended to resctrl fs is not obvious to me but I think this
> 64-bit requirement is indeed limited to x86 here? 

Just x86. The specific need is for readq() to do a 64-bit read of an
event counter from MMIO space.

> About the unconditional inclusion I would just like to ensure that the
> resulting dependencies are reasonable for all x86.

Only Intel needs INTEL_PMT_TELEMETRY. I tested out this Kconfig dependency:

	depends on (INTEL_PMT_TELEMETRY != n) || !CPU_SUP_INTEL

and managed to configure X86_CPU_RESCTRL without INTEL_PMT_TELEMETRY for
a configuration that set CPU_SUP_AMD but not CPU_SUP_INTEL in the
"Processor type and features" -> "Supported processor vendors" menu.

Note that your need CONFIG_EXPERT=y to see this option.

> Reinette
> 
> > 
> > -Tony
> > 
> > [1] https://lore.kernel.org/all/CAHk-=whigg3hvOy7c1j1MXFy6o6CHp0g4Tc3Y-MAk+XDssHU0A@mail.gmail.com
> 
-Tony