From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: RFC: New API for PPC for vcpu mmu access Date: Thu, 10 Feb 2011 12:55:22 +0100 Message-ID: <4D53D22A.2010008@suse.de> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110209180456.4f7704b5@udp111988uds> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yoder Stuart-B08248 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "Edgar E. Iglesias" To: Scott Wood Return-path: In-Reply-To: <20110209180456.4f7704b5@udp111988uds> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Scott Wood wrote: > On Thu, 3 Feb 2011 10:19:06 +0100 > Alexander Graf wrote: > > >> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is as follows: >> >> * kvm goes to qemu >> * qemu fetches all mmu and register data from kvm >> * qemu runs its mmu resolution function as if the target was emulated >> >> So the "normal" way would be to fetch _all_ TLB entries from KVM, shove them into env and implement the MMU in qemu (at least enough of it to enable debugging). No other target modifies this code path. But no other target needs to copy > 30kb of data only to get the mmu data either :). >> > > I guess you mean that cpu_synchronize_state() is supposed to pull in the > MMU state, though I don't see where it gets called for 'm'/'M' commands in > the gdb stub. > Well, we could also call it in get_phys_page_debug in target-ppc, but yes. I guess the reason it works for now is that SDR1 is pretty constant and was fetched earlier on. For BookE not syncing is obviously even more broken. > The MMU code seems to be pretty target-specific. It's not clear to what > extent there is a "normal" way, versus what book3s happens to rely on in > its get_physical_address() code. I don't think there are any platforms > supported yet (with both KVM and a non-empty cpu_get_phys_page_debug() > implementation) that have a pure software-managed TLB. x86 has page > tables, and book3s has the hash table (603/e300 doesn't, or more accurately > Linux doesn't use it, but I guess that's not supported by KVM yet?). > As for PPC, only 440, e500 and G3-5 are basically supported. It happens to work on POWER4 and above too and I've even got reports that it's good on e600 :). > We could probably do some sort of lazy state transfer only when MMU code > that needs it is run. This could initially include debug translations, for > testing a non-KVM-dependent get_physical_address() implementation, but > eventually that would use KVM_TRANSLATE (when KVM is used) and thus not > Yup :). > trigger the state transfer. I'd also like to add an "info tlb" command, > which would require the state transfer. > Very nice. > BTW, how much other than the MMU is missing to be able to run an e500 > target in qemu, without kvm? > The last person working on BookE emulation was Edgar. Edgar, how far did you get? Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56230 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnV7X-0000Zk-2P for qemu-devel@nongnu.org; Thu, 10 Feb 2011 06:55:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnV7M-00058k-M5 for qemu-devel@nongnu.org; Thu, 10 Feb 2011 06:55:26 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36322 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnV7M-00058G-AE for qemu-devel@nongnu.org; Thu, 10 Feb 2011 06:55:24 -0500 Message-ID: <4D53D22A.2010008@suse.de> Date: Thu, 10 Feb 2011 12:55:22 +0100 From: Alexander Graf MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110209180456.4f7704b5@udp111988uds> In-Reply-To: <20110209180456.4f7704b5@udp111988uds> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Yoder Stuart-B08248 , "Edgar E. Iglesias" , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , "qemu-devel@nongnu.org" Scott Wood wrote: > On Thu, 3 Feb 2011 10:19:06 +0100 > Alexander Graf wrote: > > >> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is as follows: >> >> * kvm goes to qemu >> * qemu fetches all mmu and register data from kvm >> * qemu runs its mmu resolution function as if the target was emulated >> >> So the "normal" way would be to fetch _all_ TLB entries from KVM, shove them into env and implement the MMU in qemu (at least enough of it to enable debugging). No other target modifies this code path. But no other target needs to copy > 30kb of data only to get the mmu data either :). >> > > I guess you mean that cpu_synchronize_state() is supposed to pull in the > MMU state, though I don't see where it gets called for 'm'/'M' commands in > the gdb stub. > Well, we could also call it in get_phys_page_debug in target-ppc, but yes. I guess the reason it works for now is that SDR1 is pretty constant and was fetched earlier on. For BookE not syncing is obviously even more broken. > The MMU code seems to be pretty target-specific. It's not clear to what > extent there is a "normal" way, versus what book3s happens to rely on in > its get_physical_address() code. I don't think there are any platforms > supported yet (with both KVM and a non-empty cpu_get_phys_page_debug() > implementation) that have a pure software-managed TLB. x86 has page > tables, and book3s has the hash table (603/e300 doesn't, or more accurately > Linux doesn't use it, but I guess that's not supported by KVM yet?). > As for PPC, only 440, e500 and G3-5 are basically supported. It happens to work on POWER4 and above too and I've even got reports that it's good on e600 :). > We could probably do some sort of lazy state transfer only when MMU code > that needs it is run. This could initially include debug translations, for > testing a non-KVM-dependent get_physical_address() implementation, but > eventually that would use KVM_TRANSLATE (when KVM is used) and thus not > Yup :). > trigger the state transfer. I'd also like to add an "info tlb" command, > which would require the state transfer. > Very nice. > BTW, how much other than the MMU is missing to be able to run an e500 > target in qemu, without kvm? > The last person working on BookE emulation was Edgar. Edgar, how far did you get? Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Thu, 10 Feb 2011 11:55:22 +0000 Subject: Re: RFC: New API for PPC for vcpu mmu access Message-Id: <4D53D22A.2010008@suse.de> List-Id: References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110209180456.4f7704b5@udp111988uds> In-Reply-To: <20110209180456.4f7704b5@udp111988uds> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Scott Wood Cc: Yoder Stuart-B08248 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "Edgar E. Iglesias" Scott Wood wrote: > On Thu, 3 Feb 2011 10:19:06 +0100 > Alexander Graf wrote: > > >> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is as follows: >> >> * kvm goes to qemu >> * qemu fetches all mmu and register data from kvm >> * qemu runs its mmu resolution function as if the target was emulated >> >> So the "normal" way would be to fetch _all_ TLB entries from KVM, shove them into env and implement the MMU in qemu (at least enough of it to enable debugging). No other target modifies this code path. But no other target needs to copy > 30kb of data only to get the mmu data either :). >> > > I guess you mean that cpu_synchronize_state() is supposed to pull in the > MMU state, though I don't see where it gets called for 'm'/'M' commands in > the gdb stub. > Well, we could also call it in get_phys_page_debug in target-ppc, but yes. I guess the reason it works for now is that SDR1 is pretty constant and was fetched earlier on. For BookE not syncing is obviously even more broken. > The MMU code seems to be pretty target-specific. It's not clear to what > extent there is a "normal" way, versus what book3s happens to rely on in > its get_physical_address() code. I don't think there are any platforms > supported yet (with both KVM and a non-empty cpu_get_phys_page_debug() > implementation) that have a pure software-managed TLB. x86 has page > tables, and book3s has the hash table (603/e300 doesn't, or more accurately > Linux doesn't use it, but I guess that's not supported by KVM yet?). > As for PPC, only 440, e500 and G3-5 are basically supported. It happens to work on POWER4 and above too and I've even got reports that it's good on e600 :). > We could probably do some sort of lazy state transfer only when MMU code > that needs it is run. This could initially include debug translations, for > testing a non-KVM-dependent get_physical_address() implementation, but > eventually that would use KVM_TRANSLATE (when KVM is used) and thus not > Yup :). > trigger the state transfer. I'd also like to add an "info tlb" command, > which would require the state transfer. > Very nice. > BTW, how much other than the MMU is missing to be able to run an e500 > target in qemu, without kvm? > The last person working on BookE emulation was Edgar. Edgar, how far did you get? Alex