Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2504858imu; Thu, 10 Jan 2019 15:37:54 -0800 (PST) X-Google-Smtp-Source: ALg8bN6lX/Ll8PCmI7COQYd6nQ44fqKRoaj0TgiVpV7qt8MRddqT5AoVgp58mb03TOzyHP146R88 X-Received: by 2002:a62:6cc9:: with SMTP id h192mr12152864pfc.223.1547163474787; Thu, 10 Jan 2019 15:37:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547163474; cv=none; d=google.com; s=arc-20160816; b=OTd24JU8FqN79P01zT9yYmFAYtewgfzPSJXjqt6ZAWcA0NRvCb74rPftFwp6cOm3j5 eeiaLT2DVNqKW585UvmaQvbQtjZyjQiukM8oar66uBK8vHaAmOtNtCS3RdZDyobiNjUg FdDloS+IT9zXwvt0x0fqp6SU0YuwAP57y8AOvU2JIg1uYxTMs9G3BMRZ/vejQksEc9q3 OKvxhSUQQhv4duEizZ9TeNSC2TMQsoHiwog5Xs6hNXQ2JY5rNHUcXFnqyf/9fLXjqRZ5 csb+qnUu72b9JrYXTJMgQBKjzZ5eNvNC0ThyvT18ERa2pS4ahr5OH4rKuhC9vBcpaE2A 7Lnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=IhcV6qrqahJLaDU93MwbPjpukU4mAf1x278viVCTwtY=; b=sSAqx1aRI7wnF+KNbFffgJZqCA4i6Z1X5pEaGetMXVxStdNhGuSi2rtNdRIOe7StqU y9diGM8RUz+yKnoEel+kRp2VtAYQ3a2aExjWVI1m5ykXcAKwx7buoj4SDFIMMtQXG5ob hyR5OYMRy9O4BKdJ3Ha6F8xTzH7WE8WK8xxI/B6AGPL8ovKtYj2iCYfRoGV+yYYzmglO DLR+Mt3K4eio+/dEDKeFNTdrMnAIdO3eIwQrLvVRNHENnfRfeFaYaik85vBtn4KRHddw 1cClyklrJLOasOK0Jii8xqlXOXl8H7PtSdaDFvH8J7J2IgW1gp5Dz0nTzi58NF2Awgod ckbw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h19si24417380pgg.274.2019.01.10.15.37.39; Thu, 10 Jan 2019 15:37:54 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730335AbfAJUcQ (ORCPT + 99 others); Thu, 10 Jan 2019 15:32:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58278 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728847AbfAJUcQ (ORCPT ); Thu, 10 Jan 2019 15:32:16 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5AF30DC901; Thu, 10 Jan 2019 20:32:15 +0000 (UTC) Received: from treble (ovpn-125-32.rdu2.redhat.com [10.10.125.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FB4B1054FAE; Thu, 10 Jan 2019 20:32:09 +0000 (UTC) Date: Thu, 10 Jan 2019 14:32:07 -0600 From: Josh Poimboeuf To: Nadav Amit Cc: X86 ML , LKML , Ard Biesheuvel , Andy Lutomirski , Steven Rostedt , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira Subject: Re: [PATCH v3 0/6] Static calls Message-ID: <20190110203207.3k43gt4kcvry7us7@treble> References: <20190110164401.g747vifrppbhbo3o@treble> <20190110181807.irh2b7fk6at43rdl@treble> <3F89FB6B-DA8B-4C71-B825-2B7EB86F274E@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3F89FB6B-DA8B-4C71-B825-2B7EB86F274E@vmware.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 10 Jan 2019 20:32:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 10, 2019 at 07:45:26PM +0000, Nadav Amit wrote: > >> I’m not GCC expert either and writing this code was not making me full of > >> joy, etc.. I’ll be happy that my code would be reviewed, but it does work. I > >> don’t think an early pass is needed, as long as hardware registers were not > >> allocated. > >> > >>> Would it work with more than 5 arguments, where args get passed on the > >>> stack? > >> > >> It does. > >> > >>> At the very least, it would (at least partially) defeat the point of the > >>> callee-saved paravirt ops. > >> > >> Actually, I think you can even deal with callee-saved functions and remove > >> all the (terrible) macros. You would need to tell the extension not to > >> clobber the registers through a new attribute. > > > > Ok, it does sound interesting then. I assume you'll be sharing the > > code? > > Of course. If this what is going to convince, I’ll make a small version for > PV callee-saved first. It wasn't *only* the PV callee-saved part which interested me, so if you already have something which implements the other parts, I'd still like to see it. > >>> What if we just used a plugin in a simpler fashion -- to do call site > >>> alignment, if necessary, to ensure the instruction doesn't cross > >>> cacheline boundaries. This could be done in a later pass, with no side > >>> effects other than code layout. And it would allow us to avoid > >>> breakpoints altogether -- again, assuming somebody can verify that > >>> intra-cacheline call destination writes are atomic with respect to > >>> instruction decoder reads. > >> > >> The plugin should not be able to do so. Layout of the bytecode is done by > >> the assembler, so I don’t think a plugin would help you with this one. > > > > Actually I think we could use .bundle_align_mode for this purpose: > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbinutils%2Fdocs-2.31%2Fas%2FBundle-directives.html&data=02%7C01%7Cnamit%40vmware.com%7Cfa29fb8be208498d039008d67727fe30%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636827411004664549&sdata=elDuAVOsSlidG7pZSZfjbhrgnMOHeX6AWKs0hJM4cCE%3D&reserved=0 > > Hm… I don’t understand what you have in mind (i.e., when would this > assembly directives would be emitted). For example, it could replace callq ____static_call_tramp_my_key with .bundle_align_mode 6 callq ____static_call_tramp_my_key .bundle_align_mode 0 which ensures the instruction is within a cache line, aligning it with NOPs if necessary. That would allow my current implementation to upgrade out-of-line calls to inline calls 100% of the time, instead of 95% of the time. -- Josh