[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