On 02/13/2011 09:56 AM, Alexander Graf wrote:
This interface could also be used to implement hypercall based interfaces on
s390 and x86.
The arguments will have to be extracted from the CPU state but I don't think
we'll really ever have common hypercall implementations anyway so that's not a
huge problem.
Is there enough common ground between the hypercall interfaces that this makes
sense?
Between the dispatch, registration, and tracing, yes.
It sounds nice on paper, but in the end the "hypercall not implemented"
return codes differ, the argument interpretation differs and even the amount of return
values differ.
Yes, that's why we pass CPUState. But keep in mind, CPUState needs to
be sync'd before and after the invocation.
So at the end of the day, all this interface could do is call a machine helper
function to evaluate the hypercall id from its register state and dispatch to
that, leaving the rest to the individual hypercall function implementation.
The implementations themselves also couldn't be reused. A PAPR hypercall simply
doesn't work on x86. PIO and MMIO interfaces make sense to share - devices
implemented using them could potentially be reused later by other platforms.
For the hypercall devices, that doesn't work.
Yes, which is why I'm not advocating trying to unmarshal the calls or
anything like that. But the dispatch, registration, tracing, and CPU
sync'ing bits can all be reused.
Regards,
Anthony Liguori
