[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46EB0136.6080105@codemonkey.ws>
Date: Fri, 14 Sep 2007 16:46:30 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: kvm-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Avi Kivity <avi@...ranet.com>
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
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
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists