From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: RFC: New API for PPC for vcpu mmu access Date: Fri, 11 Feb 2011 14:53:40 -0600 Message-ID: <20110211145340.70c5812b@udp111988uds> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Yoder Stuart-B08248 , , "kvm@vger.kernel.org list" , "qemu-devel@nongnu.org List" To: Alexander Graf Return-path: In-Reply-To: <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, 11 Feb 2011 02:41:35 +0100 Alexander Graf wrote: > >> Maybe we should go with Avi's proposal after all and simply keep the full soft-mmu synced between kernel and user space? That way we only need a setup call at first, no copying in between and simply update the user space version whenever something changes in the guest. We need to store the TLB's contents off somewhere anyways, so all we need is an additional in-kernel array with internal translation data, but that can be separate from the guest visible data, right? Hmm, the idea is growing on me. > So then everything we need to get all the functionality we need is a hint from kernel to user space that something changed and vice versa. > > From kernel to user space is simple. We can just document that after every RUN, all fields can be modified. > From user space to kernel, we could modify the entries directly and then pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then decide what to do with it. I guess the easiest implementation for now would be to ignore the bitmap and simply flush the shadow tlb. > > That gives us the flush almost for free. All we need to do is set the tlb to all zeros (should be done by env init anyways) and pass in the "something changed" call. KVM can then decide to simply drop all of its shadow state or loop through every shadow entry and flush it individually. Maybe we should give a hint on the amount of flushes, so KVM can implement some threshold. OK. We'll also need a config ioctl to specify MMU type/size and the address of the arrays. > Also, please tell me you didn't implement the previous revisions already. I didn't. :-) -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53841 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Po00H-0004fC-U3 for qemu-devel@nongnu.org; Fri, 11 Feb 2011 15:54:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Po00F-0002Or-JO for qemu-devel@nongnu.org; Fri, 11 Feb 2011 15:54:09 -0500 Received: from va3ehsobe004.messaging.microsoft.com ([216.32.180.14]:37575 helo=VA3EHSOBE004.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Po00F-0002OT-F4 for qemu-devel@nongnu.org; Fri, 11 Feb 2011 15:54:07 -0500 Date: Fri, 11 Feb 2011 14:53:40 -0600 From: Scott Wood Message-ID: <20110211145340.70c5812b@udp111988uds> In-Reply-To: <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Alexander Graf Cc: Yoder Stuart-B08248 , "kvm@vger.kernel.org list" , kvm-ppc@vger.kernel.org, "qemu-devel@nongnu.org List" On Fri, 11 Feb 2011 02:41:35 +0100 Alexander Graf wrote: > >> Maybe we should go with Avi's proposal after all and simply keep the full soft-mmu synced between kernel and user space? That way we only need a setup call at first, no copying in between and simply update the user space version whenever something changes in the guest. We need to store the TLB's contents off somewhere anyways, so all we need is an additional in-kernel array with internal translation data, but that can be separate from the guest visible data, right? Hmm, the idea is growing on me. > So then everything we need to get all the functionality we need is a hint from kernel to user space that something changed and vice versa. > > From kernel to user space is simple. We can just document that after every RUN, all fields can be modified. > From user space to kernel, we could modify the entries directly and then pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then decide what to do with it. I guess the easiest implementation for now would be to ignore the bitmap and simply flush the shadow tlb. > > That gives us the flush almost for free. All we need to do is set the tlb to all zeros (should be done by env init anyways) and pass in the "something changed" call. KVM can then decide to simply drop all of its shadow state or loop through every shadow entry and flush it individually. Maybe we should give a hint on the amount of flushes, so KVM can implement some threshold. OK. We'll also need a config ioctl to specify MMU type/size and the address of the arrays. > Also, please tell me you didn't implement the previous revisions already. I didn't. :-) -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 11 Feb 2011 20:53:40 +0000 Subject: Re: RFC: New API for PPC for vcpu mmu access Message-Id: <20110211145340.70c5812b@udp111988uds> List-Id: References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> <20110210125112.6d1f0380@udp111988uds> <8ACEDFEA-AA7F-400F-88F1-5F99864E8AAF@suse.de> <63E8AA2B-685F-4360-9BC8-E760A2CAD570@suse.de> <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> In-Reply-To: <49812881-9E7C-4295-B708-CFA986EE9500@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Yoder Stuart-B08248 , kvm-ppc@vger.kernel.org, "kvm@vger.kernel.org list" , "qemu-devel@nongnu.org List" On Fri, 11 Feb 2011 02:41:35 +0100 Alexander Graf wrote: > >> Maybe we should go with Avi's proposal after all and simply keep the full soft-mmu synced between kernel and user space? That way we only need a setup call at first, no copying in between and simply update the user space version whenever something changes in the guest. We need to store the TLB's contents off somewhere anyways, so all we need is an additional in-kernel array with internal translation data, but that can be separate from the guest visible data, right? Hmm, the idea is growing on me. > So then everything we need to get all the functionality we need is a hint from kernel to user space that something changed and vice versa. > > From kernel to user space is simple. We can just document that after every RUN, all fields can be modified. > From user space to kernel, we could modify the entries directly and then pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then decide what to do with it. I guess the easiest implementation for now would be to ignore the bitmap and simply flush the shadow tlb. > > That gives us the flush almost for free. All we need to do is set the tlb to all zeros (should be done by env init anyways) and pass in the "something changed" call. KVM can then decide to simply drop all of its shadow state or loop through every shadow entry and flush it individually. Maybe we should give a hint on the amount of flushes, so KVM can implement some threshold. OK. We'll also need a config ioctl to specify MMU type/size and the address of the arrays. > Also, please tell me you didn't implement the previous revisions already. I didn't. :-) -Scott