Ingo Molnar wrote: > * Avi Kivity <[EMAIL PROTECTED]> 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. > >
Agreed, let's make it so. When you say "pointer-passed" you mean physical address passed, right? ;-) -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
