All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Xin Li <xin3.li@intel.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	kvm@vger.kernel.org
Cc: mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com,
	seanjc@google.com, pbonzini@redhat.com, ravi.v.shankar@intel.com,
	jiangshanlai@gmail.com, shan.kang@intel.com
Subject: Re: [PATCH v8 21/33] x86/fred: FRED initialization code
Date: Mon, 05 Jun 2023 15:41:37 +0200	[thread overview]
Message-ID: <87cz2a6n72.ffs@tglx> (raw)
In-Reply-To: <20230410081438.1750-22-xin3.li@intel.com>

On Mon, Apr 10 2023 at 01:14, Xin Li wrote:
>  
> +/*
> + * The actual assembly entry and exit points
> + */
> +extern __visible void fred_entrypoint_user(void);

Why is this defined in this patch and not at the point where the
function is introduced?

> +/*
> + * Initialization
> + */
> +void cpu_init_fred_exceptions(void);
> +void fred_setup_apic(void);
> +
>  #endif /* __ASSEMBLY__ */
>  
> +#else
> +#define cpu_init_fred_exceptions() BUG()
> +#define fred_setup_apic() BUG()

static inline stubs please.

> @@ -2054,28 +2055,6 @@ static void wrmsrl_cstar(unsigned long val)
>  /* May not be marked __init: used by software suspend */
>  void syscall_init(void)
>  {
> -	wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);
> -	wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
> -
> -#ifdef CONFIG_IA32_EMULATION
> -	wrmsrl_cstar((unsigned long)entry_SYSCALL_compat);
> -	/*
> -	 * This only works on Intel CPUs.
> -	 * On AMD CPUs these MSRs are 32-bit, CPU truncates MSR_IA32_SYSENTER_EIP.
> -	 * This does not cause SYSENTER to jump to the wrong location, because
> -	 * AMD doesn't allow SYSENTER in long mode (either 32- or 64-bit).
> -	 */
> -	wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS);
> -	wrmsrl_safe(MSR_IA32_SYSENTER_ESP,
> -		    (unsigned long)(cpu_entry_stack(smp_processor_id()) + 1));
> -	wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat);
> -#else
> -	wrmsrl_cstar((unsigned long)ignore_sysret);
> -	wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG);
> -	wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL);
> -	wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL);
> -#endif
> -
>  	/*
>  	 * Flags to clear on syscall; clear as much as possible
>  	 * to minimize user space-kernel interference.
> @@ -2086,6 +2065,41 @@ void syscall_init(void)
>  	       X86_EFLAGS_IF|X86_EFLAGS_DF|X86_EFLAGS_OF|
>  	       X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_RF|
>  	       X86_EFLAGS_AC|X86_EFLAGS_ID);
> +
> +	/*
> +	 * The default user and kernel segments
> +	 */
> +	wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);
> +
> +	if (cpu_feature_enabled(X86_FEATURE_FRED)) {
> +		/* Both sysexit and sysret cause #UD when FRED is enabled */
> +		wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL);
> +	} else {
> +		wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
> +
> +#ifdef CONFIG_IA32_EMULATION
> +		wrmsrl_cstar((unsigned long)entry_SYSCALL_compat);
> +		/*
> +		 * This only works on Intel CPUs.
> +		 * On AMD CPUs these MSRs are 32-bit, CPU truncates
> +		 * MSR_IA32_SYSENTER_EIP.
> +		 * This does not cause SYSENTER to jump to the wrong
> +		 * location, because AMD doesn't allow SYSENTER in
> +		 * long mode (either 32- or 64-bit).
> +		 */
> +		wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_ESP,
> +			    (unsigned long)(cpu_entry_stack(smp_processor_id()) + 1));
> +		wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat);
> +#else
> +		wrmsrl_cstar((unsigned long)ignore_sysret);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL);
> +		wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL);
> +#endif
> +	}
>  }

Sigh. Can you please split this into

static void idt_syscall_init(void)
{
        All the existing gunk
}

void syscall_init(void)
{
	/* The default user and kernel segments */
	wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);

        idt_syscall_init();
}

in a first step and then in the next patch add the FRED muck?

> +/*
> + * Initialize FRED on this CPU. This cannot be __init as it is called
> + * during CPU hotplug.

Really no need to repeat this comment vs. __init all over the place.

> + */
> +void cpu_init_fred_exceptions(void)
> +{
> +	wrmsrl(MSR_IA32_FRED_CONFIG,
> +	       FRED_CONFIG_REDZONE | /* Reserve for CALL emulation */

Please don't use tail comments. Nowhere.

> +	       FRED_CONFIG_INT_STKLVL(0) |
> +	       FRED_CONFIG_ENTRYPOINT(fred_entrypoint_user));
> +
> +/*
> + * Initialize system vectors from a FRED perspective, so
> + * lapic_assign_system_vectors() can do its job.
> + */
> +void __init fred_setup_apic(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < FIRST_EXTERNAL_VECTOR; i++)
> +		set_bit(i, system_vectors);

> +	/*
> +	 * Don't set the non assigned system vectors in the
> +	 * system_vectors bitmap. Otherwise they show up in
> +	 * /proc/interrupts.
> +	 */
> +#ifdef CONFIG_SMP
> +	set_bit(IRQ_MOVE_CLEANUP_VECTOR, system_vectors);
> +#endif
> +
> +	for (i = 0; i < NR_SYSTEM_VECTORS; i++) {
> +		if (get_system_interrupt_handler(i) != NULL) {

This _cannot be NULL. The system vector table must be fully populated
with either the real handler or the spurious handler. Otherwise you need
a NULL pointer check in the dispatch path.

> +			set_bit(i + FIRST_SYSTEM_VECTOR, system_vectors);
> +		}
> +	}


> +
> +	/* The rest are fair game... */

Can you please refrain from adding useless comments. Commenting the
obvious is a distraction and not helpful in any way. Comment the things
which are not obvious in the first place.

> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -1537,6 +1537,14 @@ static system_interrupt_handler system_interrupt_handlers[NR_SYSTEM_VECTORS] = {
>  
>  #undef SYSV
>  
> +system_interrupt_handler get_system_interrupt_handler(unsigned int i)
> +{
> +	if (i >= NR_SYSTEM_VECTORS)
> +		return NULL;

Seriously?

> +	return system_interrupt_handlers[i];

Get rid of this completely confusing and useless function and look the
table up at the only call site. I'm all for defensive programming, but
this is hideous.

Thanks,

        tglx

  parent reply	other threads:[~2023-06-05 13:41 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10  8:14 [PATCH v8 00/33] x86: enable FRED for x86-64 Xin Li
2023-04-10  8:14 ` [PATCH v8 01/33] x86/traps: let common_interrupt() handle IRQ_MOVE_CLEANUP_VECTOR Xin Li
2023-05-07 11:59   ` Borislav Petkov
2023-06-03 19:19     ` Li, Xin3
2023-06-03 20:51   ` Thomas Gleixner
2023-06-05 17:07     ` Thomas Gleixner
2023-06-05 17:09       ` H. Peter Anvin
2023-06-06 20:09         ` Thomas Gleixner
2023-06-06 23:16           ` Li, Xin3
2023-06-19  8:00           ` Li, Xin3
2023-06-19 14:22             ` Thomas Gleixner
2023-06-19 18:47               ` Li, Xin3
2023-06-19 19:16                 ` H. Peter Anvin
2023-06-20  0:04                   ` Li, Xin3
2023-04-10  8:14 ` [PATCH v8 02/33] x86/fred: make unions for the cs and ss fields in struct pt_regs Xin Li
2023-06-03  9:48   ` Borislav Petkov
2023-06-05 12:07   ` Thomas Gleixner
2023-06-05 17:12     ` H. Peter Anvin
2023-06-05 17:29       ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 03/33] x86/traps: add a system interrupt table for system interrupt dispatch Xin Li
2023-06-05  8:34   ` Thomas Gleixner
2023-06-06  8:05     ` Li, Xin3
2023-06-05  8:38   ` Thomas Gleixner
2023-06-05  8:39   ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 04/33] x86/traps: add install_system_interrupt_handler() Xin Li
2023-06-05  8:57   ` Thomas Gleixner
2023-06-06  5:46     ` Li, Xin3
2023-04-10  8:14 ` [PATCH v8 05/33] x86/traps: add external_interrupt() to dispatch external interrupts Xin Li
2023-06-05 11:56   ` Thomas Gleixner
2023-06-05 17:52     ` Thomas Gleixner
2023-06-19 19:16     ` Li, Xin3
2023-06-19 21:13       ` Thomas Gleixner
2023-06-20  0:16         ` Li, Xin3
2023-04-10  8:14 ` [PATCH v8 06/33] x86/cpufeature: add the cpu feature bit for FRED Xin Li
2023-04-10  8:14 ` [PATCH v8 07/33] x86/opcode: add ERETU, ERETS instructions to x86-opcode-map Xin Li
2023-04-10  8:14 ` [PATCH v8 08/33] x86/objtool: teach objtool about ERETU and ERETS Xin Li
2023-04-10  8:14 ` [PATCH v8 09/33] x86/cpu: add X86_CR4_FRED macro Xin Li
2023-06-05 12:01   ` Thomas Gleixner
2023-06-05 17:06     ` H. Peter Anvin
2023-06-05 17:19     ` H. Peter Anvin
2023-04-10  8:14 ` [PATCH v8 10/33] x86/fred: add Kconfig option for FRED (CONFIG_X86_FRED) Xin Li
2023-04-10  8:14 ` [PATCH v8 11/33] x86/fred: if CONFIG_X86_FRED is disabled, disable FRED support Xin Li
2023-04-10  8:14 ` [PATCH v8 12/33] x86/cpu: add MSR numbers for FRED configuration Xin Li
2023-04-10  8:14 ` [PATCH v8 13/33] x86/fred: header file for event types Xin Li
2023-04-10  8:14 ` [PATCH v8 14/33] x86/fred: header file with FRED definitions Xin Li
2023-04-10  8:14 ` [PATCH v8 15/33] x86/fred: reserve space for the FRED stack frame Xin Li
2023-04-10  8:14 ` [PATCH v8 16/33] x86/fred: add a page fault entry stub for FRED Xin Li
2023-04-10  8:14 ` [PATCH v8 17/33] x86/fred: add a debug " Xin Li
2023-04-10  8:14 ` [PATCH v8 18/33] x86/fred: add a NMI " Xin Li
2023-04-10  8:14 ` [PATCH v8 19/33] x86/fred: add a machine check " Xin Li
2023-04-10  8:14 ` [PATCH v8 20/33] x86/fred: FRED entry/exit and dispatch code Xin Li
2023-06-05 13:21   ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 21/33] x86/fred: FRED initialization code Xin Li
2023-06-05 12:15   ` Thomas Gleixner
2023-06-05 13:41   ` Thomas Gleixner [this message]
2023-04-10  8:14 ` [PATCH v8 22/33] x86/fred: update MSR_IA32_FRED_RSP0 during task switch Xin Li
2023-04-10  8:14 ` [PATCH v8 23/33] x86/fred: let ret_from_fork() jmp to fred_exit_user when FRED is enabled Xin Li
2023-04-10  8:14 ` [PATCH v8 24/33] x86/fred: disallow the swapgs instruction " Xin Li
2023-06-05 13:47   ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 25/33] x86/fred: no ESPFIX needed " Xin Li
2023-04-10  8:14 ` [PATCH v8 26/33] x86/fred: allow single-step trap and NMI when starting a new thread Xin Li
2023-06-05 13:50   ` Thomas Gleixner
2023-06-05 13:52     ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 27/33] x86/fred: fixup fault on ERETU by jumping to fred_entrypoint_user Xin Li
2023-04-10  8:14 ` [PATCH v8 28/33] x86/ia32: do not modify the DPL bits for a null selector Xin Li
2023-04-10  8:14 ` [PATCH v8 29/33] x86/fred: allow FRED systems to use interrupt vectors 0x10-0x1f Xin Li
2023-06-05 14:06   ` Thomas Gleixner
2023-06-05 16:55     ` H. Peter Anvin
2023-04-10  8:14 ` [PATCH v8 30/33] x86/fred: allow dynamic stack frame size Xin Li
2023-06-05 14:11   ` Thomas Gleixner
2023-06-06  6:18     ` Li, Xin3
2023-06-06 13:27       ` Thomas Gleixner
2023-06-06 23:08         ` H. Peter Anvin
2023-04-10  8:14 ` [PATCH v8 31/33] x86/fred: BUG() when ERETU with %rsp not equal to that when the ring 3 event was just delivered Xin Li
2023-06-05 14:15   ` Thomas Gleixner
2023-06-05 16:42     ` H. Peter Anvin
2023-06-05 17:16       ` Thomas Gleixner
2023-04-10  8:14 ` [PATCH v8 32/33] x86/fred: disable FRED by default in its early stage Xin Li
2023-04-10  8:14 ` [PATCH v8 33/33] KVM: x86/vmx: refactor VMX_DO_EVENT_IRQOFF to generate FRED stack frames Xin Li
2023-04-10 21:50   ` Sean Christopherson
2023-04-11  5:06     ` Li, Xin3
2023-04-11 18:34       ` Sean Christopherson
2023-04-11 22:50         ` Li, Xin3
2023-04-12 18:26     ` Li, Xin3
2023-04-12 19:37       ` Sean Christopherson
2023-04-10 18:37 ` [PATCH v8 00/33] x86: enable FRED for x86-64 Dave Hansen
2023-04-10 19:14   ` Li, Xin3
2023-04-10 19:32     ` Borislav Petkov
2023-04-10 19:38       ` Dave Hansen
2023-04-10 20:52         ` Li, Xin3
2023-04-11  4:14       ` Li, Xin3
2023-04-10 18:49 ` Dave Hansen
2023-04-10 19:16   ` Li, Xin3
2023-06-05 17:11     ` Thomas Gleixner
2023-06-05 17:22 ` H. Peter Anvin
2023-06-05 17:32   ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cz2a6n72.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jiangshanlai@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=seanjc@google.com \
    --cc=shan.kang@intel.com \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.