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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
