Zachary Amsden wrote:
> H. Peter Anvin wrote:
>>
>> This code is almost entirely identical to the setgpr_wrapper in the
>> patch (except for the fact that setgpr_wrapper sets and captures *ALL*
>> the GPRs), and it seems rather pointless to use another wrapper. It
>> takes a pointer to an entrypoint (default to "cpuid; ret" in the CPUID
>> case), so it should do what you need.
>
> void (*cpuid)(unsigned int *eax, unsigned int *ebx, ...)
>
> Not quite. The paravirt_ops CPUID function is a C function which takes
> pointers to each GPR as arguments, and returns the values through those
> pointers. This doesn't allow for an entrypoint compatible with
> setgpr_wrapper, which expects the same output in both the cpuid; ret
> case and the paravirt-ops case.
>
> One could argue that the paravirt-ops CPUID should in fact emulate the
> native instruction semantics, which would make it a non-C function.
> However, until that bridge is crossed, we would need another wrapper
> after setgpr to convert the paravirt-ops CPUID back into the same format
> as native so that setgpr_wrapper can properly store the output fields
> into the common i386/x86_64 structure. What definitely should be done
> is hide this secondary wrapper in the paravirt-ops code so that your
> setgpr wrapper doesn't have to deal with weird issues like this because
> of paravirt-ops changes.
I guess what I was trying to say was that we'd use setgpr_wrapper in the
case where you have an entrypoint with native (non-C) semantics; in the
other case we'd use an alternative to setgpr_wrapper. Either way, it
sounds like we're talking about implementing paravirtualization *after*
CPU selection, i.e. we use IPI to get the thing running on the proper
CPU before invoking the paravirtualization function?
-hpa
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
