Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/18/2010 09:40 AM, Avi Kivity wrote: Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. That's surprisingly low. I get 3.7 Gflops on my home machine (1G loops, 4 fmul and 4 fadds, all independent, in 2.15 seconds; otherwise I can't saturate the pipeline). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/18/2010 09:40 AM, Avi Kivity wrote: Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. That's surprisingly low. I get 3.7 Gflops on my home machine (1G loops, 4 fmul and 4 fadds, all independent, in 2.15 seconds; otherwise I can't saturate the pipeline). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 09.02.2010, at 13:27, Avi Kivity wrote: On 02/09/2010 01:13 PM, Alexander Graf wrote: Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Well, then, the rate may be low due to virtualization overhead. Any way to compare absolute performance? So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/17/2010 06:23 PM, Alexander Graf wrote: On 17.02.2010, at 17:03, Avi Kivity wrote: On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? Yes, it would. But we don't have to care. The only thing we need to worry about is being fast enough to emulate enough FPU instructions actually used in normal guests so the guest runs in full speed. And 1000k 250k, so we can do that apparently, leaving some spare cycles for non-fpu instructions. I'm sure 250k isn't representative of a floating point intensive program (but maybe there aren't fpu intensive applications on that cpu). -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 17.02.2010, at 17:34, Avi Kivity wrote: On 02/17/2010 06:23 PM, Alexander Graf wrote: On 17.02.2010, at 17:03, Avi Kivity wrote: On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? Yes, it would. But we don't have to care. The only thing we need to worry about is being fast enough to emulate enough FPU instructions actually used in normal guests so the guest runs in full speed. And 1000k 250k, so we can do that apparently, leaving some spare cycles for non-fpu instructions. I'm sure 250k isn't representative of a floating point intensive program (but maybe there aren't fpu intensive applications on that cpu). Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. So we're 65x slower on a PowerStation. And that's for a tight FPU only loop. I'm still not convinced we're running into major problems. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/17/2010 08:07 PM, Alexander Graf wrote: On 17.02.2010, at 17:34, Avi Kivity wrote: On 02/17/2010 06:23 PM, Alexander Graf wrote: On 17.02.2010, at 17:03, Avi Kivity wrote: On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? Yes, it would. But we don't have to care. The only thing we need to worry about is being fast enough to emulate enough FPU instructions actually used in normal guests so the guest runs in full speed. And 1000k 250k, so we can do that apparently, leaving some spare cycles for non-fpu instructions. I'm sure 250k isn't representative of a floating point intensive program (but maybe there aren't fpu intensive applications on that cpu). Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. That's surprisingly low. So we're 65x slower on a PowerStation. And that's for a tight FPU only loop. I'm still not convinced we're running into major problems. Well, it's up to you. I just hope we don't end up underperforming due to this. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 09.02.2010, at 13:27, Avi Kivity wrote: On 02/09/2010 01:13 PM, Alexander Graf wrote: Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Well, then, the rate may be low due to virtualization overhead. Any way to compare absolute performance? So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 17.02.2010, at 17:34, Avi Kivity wrote: On 02/17/2010 06:23 PM, Alexander Graf wrote: On 17.02.2010, at 17:03, Avi Kivity wrote: On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? Yes, it would. But we don't have to care. The only thing we need to worry about is being fast enough to emulate enough FPU instructions actually used in normal guests so the guest runs in full speed. And 1000k 250k, so we can do that apparently, leaving some spare cycles for non-fpu instructions. I'm sure 250k isn't representative of a floating point intensive program (but maybe there aren't fpu intensive applications on that cpu). Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. So we're 65x slower on a PowerStation. And that's for a tight FPU only loop. I'm still not convinced we're running into major problems. Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/17/2010 08:07 PM, Alexander Graf wrote: On 17.02.2010, at 17:34, Avi Kivity wrote: On 02/17/2010 06:23 PM, Alexander Graf wrote: On 17.02.2010, at 17:03, Avi Kivity wrote: On 02/17/2010 04:56 PM, Alexander Graf wrote: So I changed to code according to your input by making all FPU calls explicit, getting rid of all binary patching. On the PowerStation again I'm running this code (simplified to the important instructions) using kvmctl: li r2, 0x1234 std r2, 0(r1) lfd f3, 0(r1) lfd f4, 0(r1) do_mul: fmulf0, f3, f4 b do_mul With the following kvm_stat output: dec 2236 53 exits 60797802 1171403 ext_intr 379 4 halt_wakeup 0 0 inst_emu 60795247 1171344 ld60795132 1171348 So I'm getting 1171403 fmul operations per second. And that's even with non-optimized instruction fetching. Not bad. It's a large number, but won't real hardware be three orders of magnitude faster? Yes, it would. But we don't have to care. The only thing we need to worry about is being fast enough to emulate enough FPU instructions actually used in normal guests so the guest runs in full speed. And 1000k 250k, so we can do that apparently, leaving some spare cycles for non-fpu instructions. I'm sure 250k isn't representative of a floating point intensive program (but maybe there aren't fpu intensive applications on that cpu). Now you made me check how fast the real hw is. I get about 65,000,000 fmul operations per second on it. That's surprisingly low. So we're 65x slower on a PowerStation. And that's for a tight FPU only loop. I'm still not convinced we're running into major problems. Well, it's up to you. I just hope we don't end up underperforming due to this. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/09/2010 01:13 PM, Alexander Graf wrote: Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Well, then, the rate may be low due to virtualization overhead. Any way to compare absolute performance? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/09/2010 01:13 PM, Alexander Graf wrote: Avi Kivity wrote: On 02/09/2010 01:00 PM, Alexander Graf wrote: 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. Measuring a typical Gekko application, I get about 200k-250k of fpu (incl. paired singles) instructions per second. Virtualized, yes? What's the rate on bare metal? Emulated. I can't measure anything on bare metal. Well, then, the rate may be low due to virtualization overhead. Any way to compare absolute performance? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 09:53, Avi Kivity wrote: 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. True. 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? Almost. Basically all I need to do is execute 2 FPU instructions instead of one for single instructions and paired single special instructions. So if I could patch the instruction to jump to some shared memory page, it'd become fast. At least as long as I figure out how to make sure we run with FP=0 in normal code, but with FP=1 in the special page ;). 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. Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 12:09, Avi Kivity wrote: On 02/08/2010 12:58 PM, Alexander Graf wrote: 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? Almost. Basically all I need to do is execute 2 FPU instructions instead of one for single instructions and paired single special instructions. So if I could patch the instruction to jump to some shared memory page, it'd become fast. At least as long as I figure out how to make sure we run with FP=0 in normal code, but with FP=1 in the special page ;). How do you locate a free virtual address to poke your shared memory page into? Most applications use the same virtual memory layout. I'm 100% confident we can make the region not collide with those. For applications actually doing memory mapping themselves, there is Linux, where we know the layout too, and one or two special applications. But I think it's feasible. At least for 99.9% of the cases. What if the guest kernel instantiates it later? Well, then we're screwed and need to fall back to trapping and emulating like my patch does now. I guess we could blacklist those guests. Aren't direct jumps limited in their offset? Yes. We can do an absolute branch do negative addresses, effectively jumping to 0x - x whereas x is 15 bits ~3 IIRC. That's definitely enough for at least a shared page for registers and a jump table :-). What if an exception happens in the shared memory page? Well, then the guest kernel needs to be gracious. I'm fairly sure it is ;-). It doesn't make sense to examine on which ip an interrupt occured. Patching is hard, let's go shopping. Yay :) 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. Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Yes, a real application typical for whatever use case you envision for Gekko emulation (can you shed a few words on that please). I did mention Dolphin, right? http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 13:03, Avi Kivity wrote: On 02/08/2010 01:30 PM, Alexander Graf wrote: Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Yes, a real application typical for whatever use case you envision for Gekko emulation (can you shed a few words on that please). I did mention Dolphin, right? Must have missed it. http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. I'm not opposed to merging special use cases (esp. as you're doing all of the work AND are responsible for maintainance), but I would like to be sure that it doesn't end up unusable. Yep :-). I'll try and see how far I can get on getting something real running. Then I get a feeling for how fast this whole approach is. Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/08/2010 02:05 PM, Alexander Graf wrote: http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. ... so what's the use case? server owners won't run games, and console owners don't need kvm to run games. Unless you propose to run Wii games on PlayStation, or something. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 13:15, Avi Kivity wrote: On 02/08/2010 02:05 PM, Alexander Graf wrote: http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. ... so what's the use case? server owners won't run games, and console owners don't need kvm to run games. Unless you propose to run Wii games on PlayStation, or something. It's an experiment to verify a theory I've had for quite a while, based on this talk: http://www.heise.de/fastbin/eventmanager/file/?media_id=466 The general idea is that the only difference between proprietary software and open software for a company developing open source is that they need less marketing. Simply because people outside will be aware of the products. Take Windows Server as an example. The reason people use it is because they know how to use Windows at home. They take a brand they know, usability they know and expectations they have to the server world. I think the same thing could apply to KVM. If there was a UI that's as easy to use and as user focused as virtual box, the awareness of kvm would rise because people use it on their workstations and would thus expect the same piece of software on their servers. Since I'm no UI programmer and I figured creating a usable UI takes way too long for me to spend time on, I figured I'd go with something where I could make a difference myself. And that's PPC. If you're using KVM on your game console and it works well, why not use it on your server? Also, as mentioned earlier, I've had different levels of awareness of stuff I did so far. People were extremely fascinated by and eager to see osx running on kvm. For nesting, the audience was smaller, thus the news it generated was way less. When it comes to commodity hardware (game consoles), I think the audience is a lot bigger again, thus generating more traction. The same thing happened with the PPC btw. Since Apple stopped shipping PPC based Macs, people are way less aware and way less interested in it. I'm pretty sure the number of server sales are still the same as they used to be, but because there's no commodity hardware that generates awareness, people believe it to be dead. So far for the theory. We'll see if my point gets proven soon enough I guess :-). Alex-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 09:53, Avi Kivity wrote: 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. True. 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? Almost. Basically all I need to do is execute 2 FPU instructions instead of one for single instructions and paired single special instructions. So if I could patch the instruction to jump to some shared memory page, it'd become fast. At least as long as I figure out how to make sure we run with FP=0 in normal code, but with FP=1 in the special page ;). 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. Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/08/2010 01:30 PM, Alexander Graf wrote: Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Yes, a real application typical for whatever use case you envision for Gekko emulation (can you shed a few words on that please). I did mention Dolphin, right? Must have missed it. http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. I'm not opposed to merging special use cases (esp. as you're doing all of the work AND are responsible for maintainance), but I would like to be sure that it doesn't end up unusable. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 13:03, Avi Kivity wrote: On 02/08/2010 01:30 PM, Alexander Graf wrote: Hum, so you suggest I get some real application running properly first so we can evaluate if it's fast enough? Yes, a real application typical for whatever use case you envision for Gekko emulation (can you shed a few words on that please). I did mention Dolphin, right? Must have missed it. http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. I'm not opposed to merging special use cases (esp. as you're doing all of the work AND are responsible for maintainance), but I would like to be sure that it doesn't end up unusable. Yep :-). I'll try and see how far I can get on getting something real running. Then I get a feeling for how fast this whole approach is. Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/08/2010 02:05 PM, Alexander Graf wrote: http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. ... so what's the use case? server owners won't run games, and console owners don't need kvm to run games. Unless you propose to run Wii games on PlayStation, or something. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 08.02.2010, at 13:15, Avi Kivity wrote: On 02/08/2010 02:05 PM, Alexander Graf wrote: http://www.dolphin-emu.com/ Basically I envision that this is the easiest way to do PR for KVM on PPC. Releasing this properly will instantly raise awareness and thus potentially increase our user base by a lot. IMHO it'd also help KVM in general, keeping it in the news. To me it seems the intersection of gamers with ppc desktop linux owners would be rather small. There are no ppc desktop linux owners left. Well - almost none. There's only servers and gamers. ... so what's the use case? server owners won't run games, and console owners don't need kvm to run games. Unless you propose to run Wii games on PlayStation, or something. It's an experiment to verify a theory I've had for quite a while, based on this talk: http://www.heise.de/fastbin/eventmanager/file/?media_id=466 The general idea is that the only difference between proprietary software and open software for a company developing open source is that they need less marketing. Simply because people outside will be aware of the products. Take Windows Server as an example. The reason people use it is because they know how to use Windows at home. They take a brand they know, usability they know and expectations they have to the server world. I think the same thing could apply to KVM. If there was a UI that's as easy to use and as user focused as virtual box, the awareness of kvm would rise because people use it on their workstations and would thus expect the same piece of software on their servers. Since I'm no UI programmer and I figured creating a usable UI takes way too long for me to spend time on, I figured I'd go with something where I could make a difference myself. And that's PPC. If you're using KVM on your game console and it works well, why not use it on your server? Also, as mentioned earlier, I've had different levels of awareness of stuff I did so far. People were extremely fascinated by and eager to see osx running on kvm. For nesting, the audience was smaller, thus the news it generated was way less. When it comes to commodity hardware (game consoles), I think the audience is a lot bigger again, thus generating more traction. The same thing happened with the PPC btw. Since Apple stopped shipping PPC based Macs, people are way less aware and way less interested in it. I'm pretty sure the number of server sales are still the same as they used to be, but because there's no commodity hardware that generates awareness, people believe it to be dead. So far for the theory. We'll see if my point gets proven soon enough I guess :-). Alex-- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? I might have missed it, but I didn't see the KVM_CAP and save/restore support for this. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. I might have missed it, but I didn't see the KVM_CAP and save/ restore support for this. Ah, cap again. Right. Mind if I send an patch on top of the set? As far as save/restore goes, the ioctl to get/set fprs isn't even implemented (yet)! We're really off full state migration to/from userspace yet. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. 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). -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. 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. 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 :-). Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? I might have missed it, but I didn't see the KVM_CAP and save/restore support for this. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. I might have missed it, but I didn't see the KVM_CAP and save/ restore support for this. Ah, cap again. Right. Mind if I send an patch on top of the set? As far as save/restore goes, the ioctl to get/set fprs isn't even implemented (yet)! We're really off full state migration to/from userspace yet. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. 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: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz 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. 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. 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 :-). Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] KVM: PPC: Virtualize Gekko guests
In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. Alexander Graf (18): KVM: PPC: Add QPR registers KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs KVM: PPC: Teach MMIO Signedness KVM: PPC: Add AGAIN type for emulation return KVM: PPC: Add hidden flag for paired singles KVM: PPC: Add Gekko SPRs KVM: PPC: Combine extension interrupt handlers KVM: PPC: Preload FPU when possible KVM: PPC: Fix typo in book3s_32 debug code KVM: PPC: Implement mtsr instruction emulation KVM: PPC: Make software load/store return eaddr KVM: PPC: Make ext giveup non-static KVM: PPC: Add helpers to call FPU instructions KVM: PPC: Fix error in BAT assignment KVM: PPC: Add helpers to modify ppc fields KVM: PPC: Enable program interrupt to do MMIO KVM: PPC: Reserve a chunk of memory for opcodes KVM: PPC: Implement Paired Single emulation arch/powerpc/include/asm/kvm.h |7 + arch/powerpc/include/asm/kvm_asm.h |1 + arch/powerpc/include/asm/kvm_book3s.h|8 +- arch/powerpc/include/asm/kvm_fpu.h | 45 + arch/powerpc/include/asm/kvm_host.h |6 + arch/powerpc/include/asm/kvm_ppc.h | 43 +- arch/powerpc/include/asm/reg.h | 10 + arch/powerpc/kernel/ppc_ksyms.c |2 + arch/powerpc/kvm/Makefile|2 + arch/powerpc/kvm/book3s.c| 132 +++- arch/powerpc/kvm/book3s_32_mmu.c |2 +- arch/powerpc/kvm/book3s_64_emulate.c | 94 ++- arch/powerpc/kvm/book3s_paired_singles.c | 1356 ++ arch/powerpc/kvm/emulate.c | 18 +- arch/powerpc/kvm/fpu.S | 77 ++ arch/powerpc/kvm/powerpc.c | 56 ++- 16 files changed, 1821 insertions(+), 38 deletions(-) create mode 100644 arch/powerpc/include/asm/kvm_fpu.h create mode 100644 arch/powerpc/kvm/book3s_paired_singles.c create mode 100644 arch/powerpc/kvm/fpu.S -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
