From: Anthony Liguori <anthony@codemonkey.ws>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: kvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Avi Kivity <avi@qumranet.com>
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Date: Fri, 14 Sep 2007 16:46:30 -0500 [thread overview]
Message-ID: <46EB0136.6080105@codemonkey.ws> (raw)
In-Reply-To: <46EAFBA0.4020503@goop.org>
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> The whole point of using the instruction is to allow hypercalls to be
>> used in many locations. This has the nice side effect of not
>> requiring a central hypercall initialization routine in the guest to
>> fetch the hypercall page. A PV driver can be completely independent
>> of any other code provided that it restricts itself to it's hypercall
>> namespace.
>>
>
> I see. So you take the fault, disassemble the instruction, see that its
> another CPU's vmcall instruction, and then replace it with the current
> CPU's vmcall?
>
Yup.
>> Xen is currently using 0/1/2. I had thought it was only using 0/1.
>> The intention was not to squash Xen's current CPUID usage so that it
>> would still be possible for Xen to make use of the guest code. Can we
>> agree that Xen won't squash leaves 3/4 or is it not worth trying to be
>> compatible at this point?
>>
>
> No, the point is that you're supposed to work out which hypervisor it is
> from the signature in leaf 0, and then the hypervisor can put anything
> it wants in the other leaves.
>
Yeah, see, the initial goal was to make it possible to use the KVM
paravirtualizations on other hypervisors. However, I don't think this
is really going to be possible in general so maybe it's better to just
use leaf 0. I'll let others chime in before sending a new patch.
Regards,
Anthony Liguori
> J
>
>
next prev parent reply other threads:[~2007-09-14 21:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 19:45 [PATCH] Refactor hypercall infrastructure Anthony Liguori
2007-09-14 20:53 ` Jeremy Fitzhardinge
2007-09-14 21:02 ` [kvm-devel] " Anthony Liguori
2007-09-14 21:20 ` Zachary Amsden
2007-09-14 21:44 ` Anthony Liguori
2007-09-15 3:37 ` Zachary Amsden
2007-09-15 8:08 ` Avi Kivity
2007-09-15 17:33 ` Anthony Liguori
2007-09-14 21:22 ` Jeremy Fitzhardinge
2007-09-14 21:46 ` Anthony Liguori [this message]
2007-09-14 21:52 ` Jeremy Fitzhardinge
2007-09-14 22:08 ` Anthony Liguori
2007-09-14 22:40 ` Nakajima, Jun
2007-09-14 23:00 ` Jeremy Fitzhardinge
2007-09-15 0:10 ` Nakajima, Jun
2007-09-15 0:28 ` Jeremy Fitzhardinge
2007-09-15 1:04 ` Nakajima, Jun
2007-09-15 4:53 ` Jeremy Fitzhardinge
2007-09-15 6:11 ` Nakajima, Jun
2007-09-15 18:23 ` Anthony Liguori
2007-09-17 18:14 ` Nakajima, Jun
2007-09-17 18:27 ` Anthony Liguori
2007-09-17 19:15 ` Jeremy Fitzhardinge
2007-09-17 19:33 ` Anthony Liguori
2007-09-17 19:15 ` Jeremy Fitzhardinge
2007-09-17 20:52 ` Nakajima, Jun
2007-09-15 8:00 ` Avi Kivity
2007-09-15 7:53 ` Avi Kivity
2007-09-15 2:35 ` Rusty Russell
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=46EB0136.6080105@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@qumranet.com \
--cc=jeremy@goop.org \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).