The per CPU array 'cea_exception_stacks' points to per CPU stacks
for #DB, NMI and #DF.  It is normally referenced via the #define:
__this_cpu_ist_top_va().

FRED introduced new fields in the host-state area of the VMCS for
stack levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively
corresponding to per CPU stacks for #DB, NMI and #DF.  KVM must
populate these each time a vCPU is loaded onto a CPU.

Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Tested-by: Shan Kang <shan.kang@intel.com>
---

Change in v4:
* Rewrite the change log and add comments to the export (Dave Hansen).
---
 arch/x86/mm/cpu_entry_area.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c
index 575f863f3c75..bc0d687de376 100644
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -17,6 +17,13 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(struct entry_stack_page, entry_stack_storage)
 #ifdef CONFIG_X86_64
 static DEFINE_PER_CPU_PAGE_ALIGNED(struct exception_stacks, exception_stacks);
 DEFINE_PER_CPU(struct cea_exception_stacks*, cea_exception_stacks);
+/*
+ * FRED introduced new fields in the host-state area of the VMCS for
+ * stack levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively
+ * corresponding to per CPU stacks for #DB, NMI and #DF.  KVM must
+ * populate these each time a vCPU is loaded onto a CPU.
+ */
+EXPORT_PER_CPU_SYMBOL(cea_exception_stacks);
 
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, _cea_offset);
 
-- 
2.48.1

On Fri, Mar 28, 2025 at 10:11:50AM -0700, Xin Li (Intel) wrote:
> The per CPU array 'cea_exception_stacks' points to per CPU stacks
> +/*
> + * FRED introduced new fields in the host-state area of the VMCS for
> + * stack levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively
> + * corresponding to per CPU stacks for #DB, NMI and #DF.  KVM must
> + * populate these each time a vCPU is loaded onto a CPU.
> + */
> +EXPORT_PER_CPU_SYMBOL(cea_exception_stacks);

Exporting data vs accessors for it is usually a bad idea.  Doing a
non-_GPl for such a very low level data struture is even worse.

On 4/10/25 01:53, Christoph Hellwig wrote:
> On Fri, Mar 28, 2025 at 10:11:50AM -0700, Xin Li (Intel) wrote:
>> The per CPU array 'cea_exception_stacks' points to per CPU stacks
>> +/*
>> + * FRED introduced new fields in the host-state area of the VMCS for
>> + * stack levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively
>> + * corresponding to per CPU stacks for #DB, NMI and #DF.  KVM must
>> + * populate these each time a vCPU is loaded onto a CPU.
>> + */
>> +EXPORT_PER_CPU_SYMBOL(cea_exception_stacks);
> Exporting data vs accessors for it is usually a bad idea.  Doing a
> non-_GPl for such a very low level data struture is even worse.

Big ack on this.

I don't even see a single caller of __this_cpu_ist_top_va() that's
remotely performance sensitive or that needs to be inline.

Just make the __this_cpu_ist_top/bottom_va() macros into real functions
and export __this_cpu_ist_top_va(). It's going to be a pretty tiny
function but I think that's tolerable.

On 4/10/2025 7:18 AM, Dave Hansen wrote:
> On 4/10/25 01:53, Christoph Hellwig wrote:
>> On Fri, Mar 28, 2025 at 10:11:50AM -0700, Xin Li (Intel) wrote:
>>> The per CPU array 'cea_exception_stacks' points to per CPU stacks
>>> +/*
>>> + * FRED introduced new fields in the host-state area of the VMCS for
>>> + * stack levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively
>>> + * corresponding to per CPU stacks for #DB, NMI and #DF.  KVM must
>>> + * populate these each time a vCPU is loaded onto a CPU.
>>> + */
>>> +EXPORT_PER_CPU_SYMBOL(cea_exception_stacks);
>> Exporting data vs accessors for it is usually a bad idea.  Doing a
>> non-_GPl for such a very low level data struture is even worse.
> 
> Big ack on this.
> 
> I don't even see a single caller of __this_cpu_ist_top_va() that's
> remotely performance sensitive or that needs to be inline.
> 
> Just make the __this_cpu_ist_top/bottom_va() macros into real functions
> and export __this_cpu_ist_top_va(). It's going to be a pretty tiny
> function but I think that's tolerable.
> 

Right, that does make sense to me.