Re: [PATCH 4/5] KVM: Add hypercall queue for paravirt_ops implementation

Avi Kivity
2007-06-18T15:08:46Z

Anthony Liguori wrote:
> Avi Kivity wrote:
>>>> These numbers are pretty bad. I'd like to improve them, even
>>>> without PV.
>>>
>>> I agree. Do you know what's missing at this point? There isn't a
>>> whole lot of state saving going on for the light weight exit paths
>>> for SVM.
>>
>> The SVM code doesn't even have a lightweight vmexit path.
>
> Sure it does. Quite a lot is deferred to vcpu_{load,put}.

Ah, I forgot. Yes, the syscall msrs are deferred.

>
>> For every vmexit, it does the entire thing, including vmload/vmsave
>
> I haven't had a lot of luck eliminating vmload/vmsave.
>

For x86_64, the only issue I see is with TR. Unfortunately, I don't see
a way around it.

>> , fpu switch (if needed)
>
> The FPU switch can really be avoided? Is it safe to assume that the
> KVM code isn't going to use any FPU operations?

Generally, kernel code does not use the fpu (when it does, it calls
kernel_fpu_begin() and kernel_fpu_end()). The vmx code avoids the switch.

Of course, if the guest doesn't use the fpu, the switch is avoided anyway.

>>
>> For kbuild vs. kernbench, I suspect that -j4 causes the shadow page
>> table cache to thrash. 1024 pages may be enough for a single
>> instance but not -j4. Hopefully replacing the eviction algorithm
>> (currently FIFO) will help. Otherwise we'll need to resize the cache
>> again.
>
> I naively tried to bump it to 2048 and hit a kmalloc limitation.
>

struct kvm is 22K on x86_64. Adding 1024 pointers makes it 30K. What
error did you get?

We should probably make the hashtable a pointer, and allocate vcpus
separately as well.

--
error compiling committee.c: too many arguments to function