Re: [PATCHv6 07/16] x86/vsyscall: Reorganize the #PF emulation code

["Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>]

On Fri, Jun 20, 2025 at 04:21:38PM -0700, Dave Hansen wrote:
> On 6/20/25 16:08, Andrew Cooper wrote:
> >> But, the resulting code is wonky. It needs to do something more like this:
> >>
> >> 	if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
> >> 		return false;
> >>
> >> 	if (error_code & X86_PF_INSTR))
> >> 		return __emulate_vsyscall(regs, address);
> > To do this, LASS needs a proper interlink against NX || SMEP.
> > 
> > If neither NX nor SMEP are active, the CPU does not report X86_PF_INSTR,
> > meaning that fetches are reported as plain reads.
> Interesting point.
> 
> I think the easiest way to do this is just make a cpuid_deps[] entry for
> LASS and NX. If there's a CPU where LASS is available but where NX isn't
> available, we have much bigger problems on our hands.

I am not sure what I suppose to do here.

Sohil pointed out that with LASS we get #GP on vsyscall, not #PF and PFEC
is not relevant for LASS.

So, IIUC, that's dependency of vsyscall PF on NX. Do we want to disable
vsyscall on boot if NX is not available?

BTW, why do we even support !NX on X86_64? Is there such HW?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov