From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [patch] KVM: add MSR based hypercall API Date: Tue, 9 Jan 2007 15:22:03 +0100 Message-ID: <20070109142203.GA6645@elte.hu> References: <20070109092705.GA8300@elte.hu> <45A36758.1000808@qumranet.com> <20070109103809.GA24515@elte.hu> <45A37B7A.8020709@qumranet.com> <20070109113628.GA4421@elte.hu> <45A39095.80005@qumranet.com> <20070109131733.GA28431@elte.hu> <45A39B90.6070908@qumranet.com> <20070109135318.GA3084@elte.hu> <45A3A1C6.201@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel Return-path: To: Avi Kivity Content-Disposition: inline In-Reply-To: <45A3A1C6.201-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org * Avi Kivity wrote: > >well, we can standardize on the 32-bit calling convention: eax, ecx, > >edx, ebp, etc. We can do that via the 64-bit asm. So it should be the > >same i think - just that a 32-bit guest on a 64-bit host wont be able > >to set the high bits of those registers. > > > > That uglifies 64-bit at the expense of 32-bit. I'd prefer it to be > the other way round, but it's not really an issue either way. i can pick whichever is better. If we pick 64-bit's natural register order, we at least have the chance to do the entry in assembly and then to call the hyper-call table directly? (with a default-not-taken branch leading out of this logic to a reshuffle thing if the guest is 32-bit) [ We also have the chance to let future hardware do the call for us from a MSR-programmed hypercall table, straight from the VMCALL, after it has verified that RAX is within a pre-defined boundary. ] so i'd vote for the 64-bit natural register order: return value in rax, parameters in: rdi, rsi, rdx, rcx, r8, r9. On 32-bit that would be edi, esi, edx, ecx, ebx, ebp - the last two shuffled into VCPU_REGS_R8/R9. That's 6 parameters already - should be enough - that's what Linux has itself. Whatever else must be passed in should come pointer-passed. > In any case, it needs to be documented, as other guests may not use > gcc or regparm. yeah. Once we pick one and declare it stable, it's cast into stone - wont change, ever. > >in fact it would probably be more logical to use the standard syscall > >order: eax, ebx, ecx, edx, esi, edi, ebp? > > Even better. It allows more registers and avoids a random gcc > dependency. ok. > > >+#define hypercall1(nr) \ > >+({ \ > >+ int __ret; \ > >+ \ > >+ asm (" call hypercall_addr\n" \ > >+ : "=g" (__ret) \ > >+ : "eax" (nr) \ > >+ ); \ > >+ __ret; \ > >+}) > > > shouldn't that be > > asm ("call hypercall_addr" : "=a"(__ret) : "a"(nr)) > > ? oops, yes. I was already wondering about the bogus return value printout ;) Ingo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV