Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp302724pxa; Wed, 26 Aug 2020 11:01:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxNdsSmxX7Mv2EZ6xaeaQBnPXg/P3cD51MIAy6cTiDmPVIlRzhErDyIdWRmsQ0+wuQ2Ez4 X-Received: by 2002:a17:906:5f8f:: with SMTP id a15mr17883297eju.291.1598464901131; Wed, 26 Aug 2020 11:01:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598464901; cv=none; d=google.com; s=arc-20160816; b=rYR43vag1lv/Pb1K9bstW2wteZZDr5ZeBZA3pMLmUGuoprTKcEVXYdUN64WIEnhVl8 /S/6RAc3oC9b3s60qNVJD3s1Q0TpkbJkDqDeT7J46Ingl+vzVoDCyMlpkPZhxMctzXIr scdqjkXgKYMZeJ+UmN9ey8eaQ7KBoOk1mqhvrqyQ0pH9oPPyeHXN6bzgl1+dlcwpSE6R QxY/hI2MlAKTmGoY0IHvzF3pnqwWXQ92woiU//7LCz0NteigCqai11krS3ecn1Yknhgd 5cwQt3h5qwToU4sz8hdqVi1a6dJ1NnMeanF122pHx6JvirO5qd5Rs0Es6rFcCNT1O6Ps ym6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CRoRrQcYHUn5Mk0Ql7x1j11zwUDdP7pOLytbF7UI6yA=; b=mswA47nY7VDhUI11y1/v8Rjhf/OyDWsHxWs0h+sG6WdjwKKAHl6uFOqKglNoEHGKl9 cusuyQZoDdkdoaFQuUOdwyUqElL23zFfrGagOukWQTlDnT0RSN2XoH9w3QwhQa5s+ZAb Ma+2QLrT6NaplkLsoVGzK7QawHPDwTiFg8b4+jPONSF2z4czb2hXo3Zk5K3cubSFobKS 0b0s1R4ZVY+rjSEvx68RWdfaOsSckiNzUmczUZf8rkPDx3SAbzK5Y2Q/kItXV6zRDW6R clL80pXW7f0d7BgwrRAiMm/i4tL5LCalAvrOl+zeK39PAQERt+iFzZKwB3bQeEx6+i4C NttA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WlCZi8En; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s27si1773837edw.412.2020.08.26.11.01.16; Wed, 26 Aug 2020 11:01:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WlCZi8En; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726740AbgHZSAo (ORCPT + 99 others); Wed, 26 Aug 2020 14:00:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:39246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbgHZSAh (ORCPT ); Wed, 26 Aug 2020 14:00:37 -0400 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF5D22080C for ; Wed, 26 Aug 2020 18:00:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598464837; bh=WId3BTrlpx4dFQDQ6F8bBoE8Z80/dTcpERIP1b6Ga9k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WlCZi8EnojE9mq3JsTMdB/EpU2IwvMKwp4nkRpPehl/Wjl/ingt87cxtdjE8cPlt6 +4uXgelDmcDTttV78THznZZSXI8M7WhMwgPrUNGbRk/h+zbH2gI1pHiFBOxxT1vwtJ Vojt3Y3rXd1laRtNb2Uv+FxqgBAn8TJh82ki5g10= Received: by mail-wr1-f45.google.com with SMTP id a5so2742292wrm.6 for ; Wed, 26 Aug 2020 11:00:36 -0700 (PDT) X-Gm-Message-State: AOAM5300351o9y8w6hl7L34Aw49lVRE4lj41ittwmXT9GxG8jymyrWYP 63UbWLCdC+I26hF1YL26bdQWwRlvTCylgzqwE+gtGg== X-Received: by 2002:adf:f442:: with SMTP id f2mr6093709wrp.184.1598464835295; Wed, 26 Aug 2020 11:00:35 -0700 (PDT) MIME-Version: 1.0 References: <20200826115357.3049-1-graf@amazon.com> <87k0xlv5w5.fsf@nanos.tec.linutronix.de> <87eentuwn8.fsf@nanos.tec.linutronix.de> In-Reply-To: <87eentuwn8.fsf@nanos.tec.linutronix.de> From: Andy Lutomirski Date: Wed, 26 Aug 2020 11:00:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/irq: Preserve vector in orig_ax for APIC code To: Thomas Gleixner Cc: Andy Lutomirski , Alexander Graf , X86 ML , LKML , Andrew Cooper , "Paul E. McKenney" , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon , Tom Lendacky , Wei Liu , Michael Kelley , Jason Chen CJ , Zhao Yakui , "Peter Zijlstra (Intel)" , Avi Kivity , "Herrenschmidt, Benjamin" , robketr@amazon.de, Amos Kong , Brian Gerst , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2020 at 10:47 AM Thomas Gleixner wrote: > > Andy, > > On Wed, Aug 26 2020 at 09:13, Andy Lutomirski wrote: > > On Wed, Aug 26, 2020 at 7:27 AM Thomas Gleixner wrote: > >> The below nasty hack cures it, but I hate it with a passion. I'll look > >> deeper for a sane variant. > >> > > Fundamentally, the way we overload orig_ax is problematic. I have a > > half-written series to improve it, but my series is broken. I think > > it's fixable, though. > > > > First is this patch to use some __csh bits to indicate the entry type. > > As far as I know, this patch is correct: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=dfff54208072a27909ae97ebce644c251a233ff2 > > Yes, that looks about right. > > > Then I wrote this incorrect patch: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=3a5087acb8a2cc1e88b1a55fa36c2f8bef370572 > > > > That one is wrong because the orig_ax wreckage seems to have leaked > > into user ABI -- user programs think that orig_ax has certain > > semantics on user-visible entries. > > Yes, orig_ax is pretty much user ABI for a very long time. > > > But I think that the problem in this thread could be fixed quite > > nicely by the first patch, plus a new CS_ENTRY_IRQ and allocating > > eight bits of __csh to store the vector. Then we could read out the > > vector. > > That works. Alternatively I can just store the vector in the irq > descriptor itself. That's trivial enough and can be done completely in C > independent of the stuff above. The latter sounds quite sensible to me. It does seem vaguely ridiculous to be trying to fish the vector out of pt_regs in the APIC code. --Andy