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 0xffffffff - 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-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
