Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests

[Avi Kivity <avi@redhat.com>]

On 02/08/2010 12:02 AM, Alexander Graf wrote:
>
>> It's not a good idea for the kernel either, if it happens all the
>> time.  If a typical Gekko application uses the fpu and the emulated
>> instructions intensively, performance will suck badly (as in: qemu/tcg
>> will be faster).
>>
>>      
> Yeah, I haven't really gotten far enough to run full-blown guests yet.
> So far I'm on demos and they look pretty good.
>
> But as far as intercept speed goes - I just tried running this little
> piece of code in kvmctl:
>
> .global _start
> _start:
>      li    r3, 42
>      mtsprg    0, r3
>      mfsprg    r4, 0
>      b    _start
>
> and measured the amount of exits I get on my test machine:
>
> processor    : 0
> cpu        : PPC970MP, altivec supported
> clock        : 2500.000000MHz
> revision    : 1.1 (pvr 0044 0101)
>
> --->
>
> exits      1811108
>
> I have no idea how we manage to get that many exits, but apparently we
> are. So I'm less concerned about the speed of the FPU rerouting at the
> moment.
>    

That's pretty impressive (never saw x86 with this exit rate) but it's 
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and 
the processor can probably do more).  An fpu intensive application will 
slow to a crawl.

> If it really gets unusably slow, I'd rather binary patch the guest on
> the fly in KVM according to rules set by the userspace client.

Is that even possible?  Do those register-pair instructions and 
registers map 1:1 to 970 instructions and registers?

> But we'll
> get there when it turns out to be too slow. For now I'd rather like to
> have something working at all and then improve speed :-).
>    

Well, I want to see the light at the end of the tunnel first.  Adding 
code is easy, ripping it out later not so much.

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