Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Anthony Liguori <anthony@codemonkey.ws>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/