From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: kvm-devel <kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [patch] KVM: add MSR based hypercall API
Date: Tue, 09 Jan 2007 16:08:06 +0200 [thread overview]
Message-ID: <45A3A1C6.201@qumranet.com> (raw)
In-Reply-To: <20070109135318.GA3084-X9Un+BFzKDI@public.gmane.org>
Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>
>>> Does this look good to you? I'd like the basic API to be as light as
>>> possible.
>>>
>> Won't 32-bit and 64-bit pick different registers?
>>
>> We can work around it (call is_long_mode() when decoding the
>> hypercall), but it kind of defeats the purpose of the optimization,
>> no?
>>
>
> 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.
In any case, it needs to be documented, as other guests may not use gcc
or regparm.
> I've attached my current patch (ontop of tarball) - that's one idea
> about how it could look like. Note that i didnt introduce a syscall
> function table in kvm_handle_hypercall() - this will be the more optimal
> solution until the # of hypercalls is relatively low. That way we only
> prepare the parameters that are truly needed.
>
> you are right in that we cannot call the syscall functions directly and
> that in practice we'll shuffle things around - but we have to check the
> first parameter anyway, and the shuffling isnt /that/ big of a problem.
> I wanted to keep the guest-side as low-impact as possible, so that a
> native kernel's instruction sequence is not disturbed too much by the
> presence of a NOP hypercall.
>
Yes, that makes sense.
> 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.
> +#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))
?
I don't think "eax" is a valid asm constraint, and we need to specify
eax as the return register.
--
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
next prev parent reply other threads:[~2007-01-09 14:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-09 9:27 [patch] KVM: add MSR based hypercall API Ingo Molnar
[not found] ` <20070109092705.GA8300-X9Un+BFzKDI@public.gmane.org>
2007-01-09 9:58 ` Avi Kivity
[not found] ` <45A36758.1000808-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 10:38 ` Ingo Molnar
[not found] ` <20070109103809.GA24515-X9Un+BFzKDI@public.gmane.org>
2007-01-09 11:24 ` Avi Kivity
[not found] ` <45A37B7A.8020709-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 11:36 ` Ingo Molnar
[not found] ` <20070109113628.GA4421-X9Un+BFzKDI@public.gmane.org>
2007-01-09 12:54 ` Avi Kivity
[not found] ` <45A39095.80005-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 13:17 ` Ingo Molnar
[not found] ` <20070109131733.GA28431-X9Un+BFzKDI@public.gmane.org>
2007-01-09 13:30 ` Ingo Molnar
2007-01-09 13:41 ` Avi Kivity
[not found] ` <45A39B90.6070908-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 13:53 ` Ingo Molnar
[not found] ` <20070109135318.GA3084-X9Un+BFzKDI@public.gmane.org>
2007-01-09 14:08 ` Avi Kivity [this message]
[not found] ` <45A3A1C6.201-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 14:22 ` Ingo Molnar
[not found] ` <20070109142203.GA6645-X9Un+BFzKDI@public.gmane.org>
2007-01-09 14:35 ` Avi Kivity
[not found] ` <45A3A816.6010308-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 14:38 ` Ingo Molnar
[not found] ` <20070109143832.GA10735-X9Un+BFzKDI@public.gmane.org>
2007-01-09 14:44 ` Ingo Molnar
[not found] ` <20070109144434.GA12152-X9Un+BFzKDI@public.gmane.org>
2007-01-09 14:50 ` Avi Kivity
[not found] ` <45A3ABAF.90208-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-01-09 15:04 ` Ingo Molnar
[not found] ` <20070109150424.GA16535-X9Un+BFzKDI@public.gmane.org>
2007-01-09 16:20 ` [patchset] KVM: paravirt/hypercall queue Ingo Molnar
[not found] ` <20070109162028.GA764-X9Un+BFzKDI@public.gmane.org>
2007-01-09 16:23 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45A3A1C6.201@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox