[Lguest] [PATCH] lguest: Change over to using KVM hypercalls mechanism

Matias Zabaljauregui zabaljauregui at gmail.com
Thu Oct 23 08:56:34 EST 2008


Hi all,

2008/10/19 Rusty Russell <rusty at rustcorp.com.au>:
> On Saturday 18 October 2008 11:07:11 ron minnich wrote:
>> so, I just glommed onto this. Does a lazy guy like me have to rewrite
>> plan 9 hcalls again :-)
>>
>> ron
>
> Good question... I guess we should measure performance impact.  We could
> rewrite the hypercall site to do an int 15 after the first time (rewriting
> is what kvm does, so it's allowed).  Bonus is that old code would "just
> work".

Ron, Rusty,   I just made a rudimentary performance test comparing
direct software interrupt vs invalid opcode fault vs patching.
Following Rusty's and Anthony's  suggestions, the benchmark is based
on code you can find in kvm-userspace/user/test/x86/, and basically it
 does a lot of hypercalls in a loop (I used LCALL_FLUSH_ASYNC, wich
does nothing), measuring the total count of cycles with rdtsc and then
prints the hypercall average cycle cost. I made 5 runs for every
scenario and these are the results:

-----
direct software interrupt:  2915, 2789, 2764, 2721, 2898

invalid opcode fault: 3410, 3681, 3466, 3392, 3780

patching (rewrite) technique: 2977, 2975, 2891, 2637, 2884
-----

Rewriting seems to be OK in terms of performance and as you said, old
code would just work.

But, (if I got it right)  I'd like to note that even if we use
rewriting, KVM places the hypercall arguments in a different order
than lguest does, so I guess we still need to update other guests code
so they get the arguments properly.

Ron, for Linux I think I just had to move struct lhcall_args members like this

-	unsigned long arg0, arg2, arg3, arg1;
+	unsigned long arg0, arg1, arg2, arg3;


I'm sending a patch in my next email.

regards
Matias



More information about the Lguest mailing list