Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp242650ybf; Wed, 26 Feb 2020 12:14:36 -0800 (PST) X-Google-Smtp-Source: APXvYqzJMbTbn0T74MCrIbFefbgRFL0Q1OmQY0cBXtiYh77uYspHqXeSTX6PLX8NOOL4kvRDf5ms X-Received: by 2002:a9d:6418:: with SMTP id h24mr445353otl.172.1582748076190; Wed, 26 Feb 2020 12:14:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582748076; cv=none; d=google.com; s=arc-20160816; b=rnHW1M15XMrOmDnQ8dxAzFdrInl7UQUaZvvbLRXnRZ9wzc6WkCs+Zd0+lpiPeuODPI O/BPvF2uW+BUmaPeWW91xpNiigvnLC0GGTNA/zhxqItrjB0HPR4xOKsO1o0OmEQXwkgl Z0MgR6JztRbJfJimZW/qZKNEubxfZLMYDwBwS/YUWe+RJeHIHOYwWDnbJCb8R7eP7LHw diSykb9Q3l5gektckaPUkK1pGV/Ie3jP/uwDwpvqhKvzSkkUM1/1GyMWV6rANZpWjeMv +SQwGJh+tkItqW9eHsidaLmPr1wpkZw18MQ5ZoRJ2LRKUwxmQnmDuHpHU/Tj+EnAx6Km 8k+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=4HFNSWMHZ6vyd7jwLynA3/yenH/9yhlJelRM6HdvB8s=; b=f+yEDlx+AsDL3I/FD5WbWVcN97g8wkSITMTnzUCLAIXs+kS1xgrVKXoCD8/cs30//z p55f7xDxvYtfQHxzo1kaoY7il8mOb0gYt95JrmvfiU2bCqf/zNoDtM1N3V5+sNIuz664 N1fKTKAG6O3uJwyy4zBikzM3goZWpU0bA577WEhEJ3Yn3+/Nh5CQDwLInIQHklbv2Loa ia4mPdHuFzHmVca0bMtrf8kOy+be+m2yHOrvCC7GDk7W+gV3y5O4VvFBGfBrV+qK9ztv m6vNiufFs2NFa6SwT24ea7ilc83S0sihmh80FJymmOY9gVJZbUTqutaUEX+42hQ1L9Pp Ha9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k6si311097otn.172.2020.02.26.12.14.23; Wed, 26 Feb 2020 12:14:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727445AbgBZUN7 (ORCPT + 99 others); Wed, 26 Feb 2020 15:13:59 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:59417 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727389AbgBZUN7 (ORCPT ); Wed, 26 Feb 2020 15:13:59 -0500 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j733y-0005cV-SR; Wed, 26 Feb 2020 21:13:47 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id EE577104099; Wed, 26 Feb 2020 21:13:45 +0100 (CET) From: Thomas Gleixner To: Brian Gerst Cc: LKML , the arch/x86 maintainers , Steven Rostedt , Juergen Gross , Paolo Bonzini , Arnd Bergmann Subject: Re: [patch 01/15] x86/irq: Convey vector as argument and not in ptregs In-Reply-To: References: <20200225224719.950376311@linutronix.de> <20200225231609.000955823@linutronix.de> Date: Wed, 26 Feb 2020 21:13:45 +0100 Message-ID: <87k149p0na.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Brian Gerst writes: > On Tue, Feb 25, 2020 at 6:26 PM Thomas Gleixner wrote: >> >> Device interrupts which go through do_IRQ() or the spurious interrupt >> handler have their separate entry code on 64 bit for no good reason. >> >> Both 32 and 64 bit transport the vector number through ORIG_[RE]AX in >> pt_regs. Further the vector number is forced to fit into an u8 and is >> complemented and offset by 0x80 for historical reasons. > > The reason for the 0x80 offset is so that the push instruction only > takes two bytes. This allows each entry stub to be packed into a > fixed 8 bytes. idt_setup_apic_and_irq_gates() assumes this 8-byte > fixed length for the stubs, so now every odd vector after 0x80 is > broken. > > 508: 6a 7f pushq $0x7f > 50a: e9 f1 08 00 00 jmpq e00 > 50f: 90 nop > 510: 68 80 00 00 00 pushq $0x80 > 515: e9 e6 08 00 00 jmpq e00 > 51a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) > 520: 68 81 00 00 00 pushq $0x81 > 525: e9 d6 08 00 00 jmpq e00 > 52a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) > > The 0x81 vector should start at 0x518, not 0x520. Bah, I somehow missed that big fat comment explaining it. :) Thanks for catching it. So my testing just has been lucky to not hit one of those. Now the question is whether we care about the packed stubs or just make them larger by using alignment to get rid of this silly +0x80 and ~vector fixup later on. The straight forward thing clearly has its charm and I doubt it matters in measurable ways. Thanks, tglx