* Matteo Rizzo wrote:
> On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
> >
> > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
> > user-space execution and kernel-space execution?
> >
>
> Same benchmark as before (compiling a kernel on a system running the patch
On 14.09.23 г. 7:47 ч., Xin Li wrote:
Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
into the code.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/msr.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/include/as
On Wed, Sep 20 2023 at 04:33, Li, Xin3 wrote:
>> > +static inline void fred_syscall_init(void) {
>> > + /*
>> > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL
>> > + * and SYSENTER, and ERETU is the only legit instruction to return to
>> > + * ring 3, as a result the
> > +static __always_inline void __wrmsrns(u32 msr, u32 low, u32 high)
>
> Shouldn't this be named wrmsrns_safe since it has exception handling, similar
> to
> the current wrmsrl_safe.
>
Both safe and unsafe versions have exception handling, while the safe
version returns an integer to its call
On 9/18/23 14:08, Matteo Rizzo wrote:
> On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher
>> Problems:
>>
>> - Overhead due to more TLB lookups
>>
>> - Larger amounts of TLBs are used for the OS. Currently we are trying to
>> use the maximum mappable TLBs to reduce their numbers. This presumably
On 9/15/23 12:59, Matteo Rizzo wrote:
> From: Jann Horn
>
> Document what SLAB_VIRTUAL is trying to do, how it's implemented, and
> why.
>
> Signed-off-by: Jann Horn
> Co-developed-by: Matteo Rizzo
> Signed-off-by: Matteo Rizzo
> ---
> Documentation/security/self-protection.rst | 102 +++
On 14.09.23 г. 7:47 ч., Xin Li wrote:
Briefly introduce FRED, and its advantages compared to IDT.
Signed-off-by: Xin Li
---
Documentation/arch/x86/x86_64/fred.rst | 98 +
Documentation/arch/x86/x86_64/index.rst | 1 +
2 files changed, 99 insertions(+)
create m
On 14.09.23 г. 7:47 ч., Xin Li wrote:
From: "H. Peter Anvin (Intel)"
Add CONFIG_X86_FRED to to make
cpu_feature_enabled() work correctly with FRED.
Originally-by: Megha Dey
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/disab
On 14.09.23 г. 7:47 ч., Xin Li wrote:
From: "H. Peter Anvin (Intel)"
Add X86_CR4_FRED macro for the FRED bit in %cr4. This bit must not be
changed after initialization, so add it to the pinned CR4 bits.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
On 14.09.23 г. 7:47 ч., Xin Li wrote:
FRED defines additional information in the upper 48 bits of cs/ss
fields. Therefore add the information definitions into the pt_regs
structure.
Specially introduce a new structure fred_ss to denote the FRED flags
above SS selector, which avoids FRED_SSX_
On Fri, Sep 15, 2023 at 02:16:50AM +0100, andrew.coop...@citrix.com wrote:
> Juergen has already done the work to delete one of these two patching
> mechanisms and replace it with the other.
>
> https://lore.kernel.org/lkml/a32e211f-4add-4fb2-9e5a-480ae9b9b...@suse.com/
>
> Unfortunately, it's o
On 20.09.23 17:00, Peter Zijlstra wrote:
On Fri, Sep 15, 2023 at 02:16:50AM +0100, andrew.coop...@citrix.com wrote:
Juergen has already done the work to delete one of these two patching
mechanisms and replace it with the other.
https://lore.kernel.org/lkml/a32e211f-4add-4fb2-9e5a-480ae9b9b...@
> > +struct fred_ss {
> > + u64 ss : 16, // SS selector
>
> Is this structure conformant to the return state as described in FRED 5.0?
>
> — The stack segment of the interrupted context, 64 bits formatted as follows:
>
> • Bits 15:0 contain the SS selector. < - WE HAVE THIS
>
> • B
> > +#ifdef __x86_64__
> > +#define X86_CR4_FRED_BIT 32 /* enable FRED kernel entry */
> > +#define X86_CR4_FRED _BITUL(X86_CR4_FRED_BIT)
>
> nit: s/BITUL/BITULL I guess if __x86_64__ is defined then we are
> guaranteed that unsigned long will be a 64 bit, but for the sake of
> cla
On 9/14/23 06:48, Xin Li wrote:
+ /*
+* Don't check the FRED stack level, the call stack leading to this
+* helper is effectively constant and shallow (relatively speaking).
It's more that we don't need to protect from reentrancy. The external
interrupt uses stack level
On 9/14/23 06:48, Xin Li wrote:
When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in
IRQ/NMI induced VM exits.
Tested-by: Shan Kang
Signed-off-by: Xin Li
Acked-by: Paolo Bonzini
---
arch/x86/kvm/vmx/vmx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(
> > + /*
> > +* Don't check the FRED stack level, the call stack leading to this
> > +* helper is effectively constant and shallow (relatively speaking).
>
> It's more that we don't need to protect from reentrancy. The external
> interrupt uses stack level 0 so no adjustment would be ne
On September 20, 2023 1:18:14 AM PDT, Thomas Gleixner
wrote:
>On Wed, Sep 20 2023 at 04:33, Li, Xin3 wrote:
>>> > +static inline void fred_syscall_init(void) {
>>> > + /*
>>> > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL
>>> > + * and SYSENTER, and ERETU is the only
18 matches
Mail list logo
