>
> 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
|
Home