From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests Date: Mon, 08 Feb 2010 10:53:44 +0200 Message-ID: <4B6FD118.2090207@redhat.com> References: <1265298925-31954-1-git-send-email-agraf@suse.de> <4B6EB7F6.10304@redhat.com> <4B6EE8B2.80009@redhat.com> <4B6F3890.8090401@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14572 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010Ab0BHIxs (ORCPT ); Mon, 8 Feb 2010 03:53:48 -0500 In-Reply-To: <4B6F3890.8090401@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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