[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a5hgrb1q.ffs@tglx>
Date: Tue, 13 Aug 2024 12:07:13 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org
Cc: hpa@...or.com, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, peterz@...radead.org,
andrew.cooper3@...rix.com, nik.borisov@...e.com,
houwenlong.hwl@...group.com
Subject: Re: [PATCH v2 0/3] Enable FRED earlier
On Tue, Jul 09 2024 at 08:40, Xin Li wrote:
> Wenlong Hou from Ant group reported two problems during the FRED
> initialization:
> https://lore.kernel.org/lkml/cover.1718972598.git.houwenlong.hwl@antgroup.com/
>
> The first problem is that spurious_interrupt() gets called on the
> HYPERVISOR_CALLBACK_VECTOR vector. Because kvm_guest_init(), being
> executed way before trap_init() in which it is decided that whether
> FRED will be enabled or not, calls sysvec_install() to install
> HYPERVISOR_CALLBACK_VECTOR's interrupt handler into FRED system
> vector dispatch table or IDT depending on whether FRED is enabled.
>
> The other problem is that the #PF handler gets a wrong faulting
> address from the stack instead of CR2 before FRED is enabled.
> Because the #PF handler fetches its faulting addresss from the
> stack or CR2 based on whether FRED is available rather than active.
>
> This patchset fixes the 2 problems with suggestions from tglx:
>
> 1) Parse cmdline param "fred=" in cpu_parse_early_param() to
> minimize the gap mentioned above, before kvm_guest_init().
>
> 2) Enable FRED right after init_mem_mapping() to switch to FRED
> from early IDT ASAP, avoid intermediately using the IDT #PF
> handler.
I just noticed that there is another leftover regarding FRED:
arch/x86/kernel/cpu/cpuid-deps.c:86: { X86_FEATURE_FRED, X86_FEATURE_WRMSRNS },
We removed the dependency on X86_FEATURE_WRMSRNS, right? So this is
stale and should be removed too.
Thanks,
tglx
Powered by blists - more mailing lists