Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964899Ab2B2Jeu (ORCPT ); Wed, 29 Feb 2012 04:34:50 -0500 Received: from mail-bk0-f46.google.com ([209.85.214.46]:53750 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932213Ab2B2Jeq (ORCPT ); Wed, 29 Feb 2012 04:34:46 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of dave.martin@linaro.org designates 10.204.145.155 as permitted sender) smtp.mail=dave.martin@linaro.org Date: Wed, 29 Feb 2012 09:34:36 +0000 From: Dave Martin To: Stefano Stabellini Cc: Ian Campbell , "xen-devel@lists.xensource.com" , "linaro-dev@lists.linaro.org" , "kvm@vger.kernel.org" , "arnd@arndb.de" , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , David Vrabel , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor Message-ID: <20120229093436.GA2077@linaro.org> References: <1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com> <1330360043.8557.302.camel@zakaz.uk.xensource.com> <20120227180355.GB2023@linaro.org> <1330371219.10008.34.camel@dagon.hellion.org.uk> <20120228102040.GB2063@linaro.org> <1330426133.31269.70.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5264 Lines: 113 On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote: > On Tue, 28 Feb 2012, Ian Campbell wrote: > > On Tue, 2012-02-28 at 10:20 +0000, Dave Martin wrote: > > > On Mon, Feb 27, 2012 at 07:33:39PM +0000, Ian Campbell wrote: > > > > On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote: > > > > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available > > > > > > which do allow direct mov of an immediate into R12, but are 32 bit Thumb > > > > > > instructions. > > > > > > > > > > > > Should we use r7 instead to maximise instruction density for Thumb code? > > > > > > > > > > The difference seems trivial when put into context, even if you code a > > > > > special Thumb version of the code to maximise density (the Thumb-2 code > > > > > which gets built from assembler in the kernel is very suboptimal in > > > > > size, but there simply isn't a high proportion of asm code in the kernel > > > > > anyway.) I wouldn't consider the ARM/Thumb differences as an important > > > > > factor when deciding on a register. > > > > > > > > OK, that's useful information. thanks. > > > > > > > > > One argument for _not_ using r12 for this purpose is that it is then > > > > > harder to put a generic "HVC" function (analogous to the "syscall" > > > > > syscall) out-of-line, since r12 could get destroyed by the call. > > > > > > > > For an out of line syscall(2) wouldn't the syscall number either be in a > > > > standard C calling convention argument register or on the stack when the > > > > function was called, since it is just a normal argument at that point? > > > > As you point out it cannot be passed in r12 (and could never be, due to > > > > the clobbering). > > > > > > > > The syscall function itself would have to move the arguments and syscall > > > > nr etc around before issuing the syscall. > > > > > > > > I think the same is true of a similar hypercall(2) > > > > > > > > > If you don't think you will ever care about putting HVC out of line > > > > > though, it may not matter. > > > > > > If you have both inline and out-of-line hypercalls, it's hard to ensure > > > that you never have to shuffle the registers in either case. > > > > Agreed. > > > > I think we want to optimise for the inline case since those are the > > majority. > > They are not just the majority, all of them are static inline at the > moment, even on x86 (where the number of hypercalls is much higher). > > So yes, we should optimize for the inline case. > > > > The only non-inline case is the special "privcmd ioctl" which is the > > mechanism that allows the Xen toolstack to make hypercalls. It's > > somewhat akin to syscall(2). By the time you get to it you will already > > have done a system call for the ioctl, pulled the arguments from the > > ioctl argument structure etc, plus such hypercalls are not really > > performance critical. > > Even the privcmd hypercall (privcmd_call) is a static inline function, > it is just that at the moment there is only one caller :) > > > > > Shuffling can be reduced but only at the expense of strange argument > > > ordering in some cases when calling from C -- the complexity is probably > > > not worth it. Linux doesn't bother for its own syscalls. > > > > > > Note that even in assembler, a branch from one section to a label in > > > another section may cause r12 to get destroyed, so you will need to be > > > careful about how you code the hypervisor trap handler. However, this > > > is not different from coding exception handlers in general, so I don't > > > know that it constitutes a conclusive argument on its own. > > > > We are happy to arrange that this doesn't occur on our trap entry paths, > > at least until the guest register state has been saved. Currently the > > hypercall dispatcher is in C and gets r12 from the on-stack saved state. > > We will likely eventually optimise the hypercall path directly in ASM > > and in that case we are happy to take steps to ensure we don't clobber > > r12 before we need it. > > Yes, I don't think this should be an issue. Fair enough. > > > My instinctive preference would therefore be for r7 (which also seems to > > > be good enough for Linux syscalls) -- but it really depends how many > > > arguments you expect to need to support. > > > > Apparently r7 is the frame pointer for gcc in thumb mode which I think > > is a good reason to avoid it. > > > > We currently have some 5 argument hypercalls and there have been > > occasional suggestions for interfaces which use 6 -- although none of > > them have come to reality. > > I don't have a very strong opinion on which register we should use, but > I would like to avoid r7 if it is already actively used by gcc. But there is no framepointer for Thumb-2 code (?) > The fact that r12 can be destroyed so easily is actually a good argument > for using it because it means it is less likely to contain useful data > that needs to be saved/restored by gcc. That's a fair point. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/