From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752457AbdKXEPN (ORCPT ); Thu, 23 Nov 2017 23:15:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:41226 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbdKXEPM (ORCPT ); Thu, 23 Nov 2017 23:15:12 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98BAD21995 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AGs4zMafHS06pw2PfnP6HevGbk3eT7efQvqjVt9ALqkZBG9JwnwtWnPoUMrkd1s4l3OkpGv2QDKAlBiGUkkYCf7biy0= MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Thu, 23 Nov 2017 20:14:50 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 13/18] x86/asm/64: Use a percpu trampoline stack for IDT entries To: Thomas Gleixner Cc: Andy Lutomirski , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Dave Hansen , Linus Torvalds , Josh Poimboeuf Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 23, 2017 at 3:44 PM, Thomas Gleixner wrote: > On Tue, 21 Nov 2017, Andy Lutomirski wrote: >> The asm isn't exactly beautiful, > > Delightful euphemism :) > >> but I think that fully refactoring >> it can wait. > >> @@ -560,6 +560,14 @@ END(irq_entries_start) >> .macro interrupt func >> cld >> ALLOC_PT_GPREGS_ON_STACK >> + >> + testb $3, CS(%rsp) >> + jz 1f >> + SWAPGS >> + call switch_to_thread_stack >> + SWAPGS > > I'm surely missing something subtle, but the register saving does really > not care on which GS it is. This swapgs orgy looks odd. You're mostly right. switch_to_thread_stack uses PER_CPU_VAR(cpu_current_top_of_stack), which definitely cares about which GS it's on, but there's still no legitimate reason for the SWAPGS orgy. I'll fix it. > >> +1: >> + >> SAVE_C_REGS >> SAVE_EXTRA_REGS >> ENCODE_FRAME_POINTER >> @@ -827,6 +835,33 @@ apicinterrupt IRQ_WORK_VECTOR irq_work_interrupt smp_irq_work_interrupt >> */ >> #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8) >> >> +/* >> + * Switch to the thread stack. This is called with the IRET frame and >> + * orig_ax in pt_regs and the rest of pt_regs allocated, but with all GPRs >> + * in the CPU registers. > > That took several attempts to grok why you left ALLOC_PT_GPRES_ON_STACK in > place in the interrupts macro above. > > In theory it would be sufficient to push %rdi on the entry stack and > operate from there, but it spares only the 'addq %rsp'. Not worth the > trouble of dealing with different register offsets. Hrm. There wasn't actually a good reason for that. I got rid of it.