Hi Kirill,
Sorry, this fell through the cracks (thanks to Will for reminding me).
On Sat, Jun 11, 2022 at 04:28:30AM +0300, Kirill A. Shutemov wrote:
> On Fri, Jun 10, 2022 at 08:24:38AM -0700, Dave Hansen wrote:
> > On 6/10/22 07:35, Kirill A. Shutemov wrote:
> > > +/*
> > > + * Report architecture specific information
> > > + */
> > > +int proc_pid_arch_status(struct seq_file *m, struct pid_namespace *ns,
> > > + struct pid *pid, struct task_struct *task)
> > > +{
> > > + /*
> > > + * Report AVX512 state if the processor and build option supported.
> > > + */
> > > + if (cpu_feature_enabled(X86_FEATURE_AVX512F))
> > > + avx512_status(m, task);
> > > +
> > > + seq_printf(m, "untag_mask:\t%#lx\n", mm_untag_mask(task->mm));
> > > +
> > > + return 0;
> > > +}
> >
> > Arch-specific gunk is great for, well, arch-specific stuff. AVX-512 and
> > its, um, "quirks", really won't show up anywhere else. But x86 isn't
> > even the first to be doing this address tagging business.
> >
> > Shouldn't we be talking to the ARM folks about a common way to do this?
>
> + Catalin, Will.
>
> I guess we can expose the mask via proc for ARM too, but I'm not sure if
> we can unify interface further without breaking existing TBI users: TBI is
> enabled per-thread while LAM is per-process.
Hardware TBI is enabled for all user space at boot (it was like this
form the beginning). The TBI syscall interface is per-thread (TIF flag)
but it doesn't change any hardware behaviour. The mask is fixed in
hardware, unchangeable. I'm fine with reporting an untag_mask in a
common way, only that setting it won't be possible on arm64.
If arm64 ever gains support for a modifiable untag_mask, it's a good
chance it would be per mm as well since the controls for TBI are per
page table.
--
Catalin
