>
> As for the simplest hypercall, that is xen_version.
>
Am I correct in saying that 'HYPERVISOR_xen_version(0, NULL)' is a
benign call, and that if the system doesn't crash, I'm probably on the
right track? 
So far, I get a STOP error 0x1000007e (0xC0000005, ...) which is a
'SYSTEM THREAD EXCEPTION NOT HANDLED' error, with the exception being
'ACCESS VIOLATION'.
Xen_version appears to use the two parameter version of the hypercall...
in the linux header this is defined as:
"
#define _hypercall2(type, name, a1, a2) \
({ \
 long __res, __ign1, __ign2; \
 asm volatile ( \
 HYPERCALL_STR(name) \
 : "=a" (__res), "=b" (__ign1), "=c" (__ign2) \
 : "1" ((long)(a1)), "2" ((long)(a2)) \
 : "memory" ); \
 (type)__res; \
})
"
Now the only x86 assembler I have ever done was at Uni, just over 10
years ago, so I'm guessing the probably is probably my translation to
Microsoft (Intel) compatible inline assembly here:
"
static __forceinline int
HYPERVISOR_xen_version(int cmd, void *arg)
{
 long __res;
 __asm {
 push ebp
 mov ebp, esp
 sub esp, 8
 mov eax, cmd
 mov [ebp - 8], eax
 mov eax, arg
 mov [ebp - 4], eax
 call hypercall_stubs + (__HYPERVISOR_xen_version * 32)
 add esp, 8
 pop ebp
 mov [__res], eax
 }
 return __res;
}
"
The compiler complains that I'm tinkering with ebp, but I am putting it
back afterwards so I don't see that as a problem.
When I allocate the memory for 'hypercall_stubs', I check the first two
bytes at the (__HYPERVISOR_xen_version * 32) offset before and after the
WRMSR call, and they definitely do change, so I believe the WRMSR call
is correct.
Any suggestions? Writing this email is mostly just therapeutic... so
many times I'll fuss over a problem for ages, finally send a request for
help to a mailing list, and find the problem almost immediately after,
so I'm hoping this will happen here :)
Thanks
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel