Xen devel - Sep 2007 - testing hypercall from windows - what''s the most basic call I can make to test

I''m tinkering with some code to be able to talk to the hypervisor from
Windows, with the ultimate aim to get a usable xenbus.

So far I''ve created a driver for the Xen PCI
''device'', and (hopefully)
mapped the hypercall space given by the CPUID call...

What is the simplest hypercall I can make to get an answer from the
hypervisor to tell me that it''s working?

Also, it would be really helpful if someone could validate my logic
here:
. Get the PCI details (mmio space, io space, interrupt)
. CPUID(0x40000000) to check for the XenVMMXenVMM signature
. CPUID(0x40000001) to check the Xen version
. CPUID(0x40000002) to get the number of pages for the hypercall memory
space, and the msr to use
. Allocate page-aligned, executable memory for the hypercall memory
space
. execute an WRMSR using the msr value given above and the pfn(*) of
each page
. make calls into the above space as required

(*) - It isn''t clear to me how to do this under windows... anecdotal
googling suggests I can get the physical address of the memory I
allocated and shift it right by the PAGE_SHIFT value to get the pfn, but
I thought there would be more to it than that...

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Yes, all the below is correct. You do indeed just pass in a PFN and Xen will
copy data into it. In fact the nr_pfns part of the hypercall-page setup was
misguided I think. I''ll guarantee that remains one forever more, so you
can
just allocate a single page and get quite upset if you ever see CPUID return
more than one page when interrogated via leaf 0x40000002.

As for the simplest hypercall, that is xen_version.

 -- Keir

On 24/9/07 14:27, "James Harper" <james.harper@bendigoit.com.au>
wrote:
> . Get the PCI details (mmio space, io space, interrupt)
> . CPUID(0x40000000) to check for the XenVMMXenVMM signature
> . CPUID(0x40000001) to check the Xen version
> . CPUID(0x40000002) to get the number of pages for the hypercall memory
> space, and the msr to use
> . Allocate page-aligned, executable memory for the hypercall memory
> space
> . execute an WRMSR using the msr value given above and the pfn(*) of
> each page
> . make calls into the above space as required
> 
> (*) - It isn''t clear to me how to do this under windows...
anecdotal
> googling suggests I can get the physical address of the memory I
> allocated and shift it right by the PAGE_SHIFT value to get the pfn, but
> I thought there would be more to it than that...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

I think I found the problem... the parameters are 0 based, so I need to
change:
> HYPERVISOR_xen_version(int cmd, void *arg)
> {
>   long __res;
>   __asm {
>     push ebp
>     mov ebp, esp
>     sub esp, 8
      ^^^^^^^^^^ this to ''sub esp, 12''
>     mov eax, cmd
>     mov [ebp - 8], eax
>     mov eax, arg
>     mov [ebp - 4], eax
>     call hypercall_stubs + (__HYPERVISOR_xen_version * 32)
>     add esp, 8
      ^^^^^^^^^^ and this to ''add esp,
12''
>     pop ebp
>     mov [__res], eax
>   }
>   return __res;
> }
> "
Which now doesn''t crash... I hope that''s a good sign!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> Which now doesn''t crash... I hope that''s a good sign!
> 
Well... it didn''t crash the first time I tried it, but it does now, so
I
think that first time was just a fluke, or I''d hadn''t
uncommented the
hypercall :(

The latest crash was
''ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY''... time for
sleep now though.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel