>> The hypercalls can be called with various parameters number.
>> Both x86_64 and i386 are supported.
>>
>> Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
>> ---
>> +static inline int
>> +__hypercall6(unsigned int nr, unsigned long p1, unsigned long p2,
>> + unsigned long p3, unsigned long p4, unsigned long p5,
>> + unsigned long p6)
>> +{
>> + int ret;
>> + asm (" call hypercall_addr\n"
>> + : "=a" (ret)
>> + : "b" (nr),
>> + "a" (p1),
>> + "c" (p2),
>> + "d" (p3),
>> + "S" (p4),
>> + "D" (p5),
>> + "bp" (p6)
>> + : "memory", "cc"
>> + );
>> + return ret;
>> +}
>> +
>> +#define hypercall(nr_params, args...) \
>> +({ \
>> + /* __ret is volatile to make sure call to this \
>> + * function isn't optimized away by gcc. Just \
>> + * having the __hypercallN() functions mention \
>> + * memory is clobbered isn't enough \
>> + */ \
>> + volatile int __ret; \
>> + \
>> + __ret = __hypercall##nr_params(args); \
>> + \
>> + __ret; \
>> +})
>
>A couple things are different in my patchset. I didn't do this
>hypercall macro. I tried it at first but IMHO it was pretty ugly. It
It will also simplify the call to the hypercall, instead of
hypercall(X,TYPE,...) hypercallX(Type,...)
Will be changed in the next drop.
>makes things less readable to me. The second thing is I only have up
to
>4 parameters to a hypercall. That leaves some GP registers on 32-bit
>and Xen seems to be happily using 4 registers so I don't think there's
>anything we can't express without the extra 2.
>
Agreed, actually the x86_64 has only 4 parameters too.
Thanks,
Dor.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
