From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 17 Feb 2012 18:27:39 +0000 Subject: Re: [Qemu-devel] [RFC] Next gen kvm api Message-Id: <4F3E9C1B.5040404@freescale.com> List-Id: References: <4F2AB552.2070909@redhat.com> <4F2B41D6.8020603@codemonkey.ws> <51470503-DEE0-478D-8D01-020834AF6E8C@suse.de> <4F3117E5.6000105@redhat.com> <4F31241C.70404@redhat.com> <4F313354.4080401@redhat.com> <4B03190C-1B6B-48EC-92C7-C27F6982018A@suse.de> <4F3B9497.4020700@redhat.com> <4F3BB33C.1000908@redhat.com> <1FE08D00-49E8-4371-9F23-C5D2EE568FA8@suse.de> <4F3BB9DC.6040102@redhat.com> <3DC824A5-5D5A-4BCC-A0FB-1B459B7E362D@suse.de> <4F3D57E3.7020503@redhat.com> <810F6879-64A9-4FCF-9C22-00BCC945D6B0@suse.de> <4F3D5B35.4000606@redhat.com> <4F3D6A0E.4080705@freescale.com> <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> In-Reply-To: <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Avi Kivity , Anthony Liguori , KVM list , linux-kernel , qemu-devel , kvm-ppc On 02/16/2012 06:23 PM, Alexander Graf wrote: > On 16.02.2012, at 21:41, Scott Wood wrote: >> And yes, we do have fancier hardware coming fairly soon for which this >> breaks (TLB0 entries can be loaded without host involvement, as long as >> there's a translation from guest physical to physical in a separate >> hardware table). It'd be reasonable to ignore TLB0 for migration (treat >> it as invalidated), but not for debug since that may be where the >> translation we're interested in resides. > > Could we maybe add an ioctl that forces kvm to read out the current tlb0 contents and push them to memory? How slow would that be? Yes, I was thinking something like that. We'd just have to remove (make conditional on MMU type) the statement that this is synchronized implicitly on return from vcpu_run. Performance shouldn't be a problem -- we'd only need to sync once and then can do all the repeated debug accesses we want. So should be no need to mess around with partial sync. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [Qemu-devel] [RFC] Next gen kvm api Date: Fri, 17 Feb 2012 12:27:39 -0600 Message-ID: <4F3E9C1B.5040404@freescale.com> References: <4F2AB552.2070909@redhat.com> <4F2B41D6.8020603@codemonkey.ws> <51470503-DEE0-478D-8D01-020834AF6E8C@suse.de> <4F3117E5.6000105@redhat.com> <4F31241C.70404@redhat.com> <4F313354.4080401@redhat.com> <4B03190C-1B6B-48EC-92C7-C27F6982018A@suse.de> <4F3B9497.4020700@redhat.com> <4F3BB33C.1000908@redhat.com> <1FE08D00-49E8-4371-9F23-C5D2EE568FA8@suse.de> <4F3BB9DC.6040102@redhat.com> <3DC824A5-5D5A-4BCC-A0FB-1B459B7E362D@suse.de> <4F3D57E3.7020503@redhat.com> <810F6879-64A9-4FCF-9C22-00BCC945D6B0@suse.de> <4F3D5B35.4000606@redhat.com> <4F3D6A0E.4080705@freescale.com> <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Anthony Liguori , KVM list , linux-kernel , qemu-devel , kvm-ppc To: Alexander Graf Return-path: In-Reply-To: <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02/16/2012 06:23 PM, Alexander Graf wrote: > On 16.02.2012, at 21:41, Scott Wood wrote: >> And yes, we do have fancier hardware coming fairly soon for which this >> breaks (TLB0 entries can be loaded without host involvement, as long as >> there's a translation from guest physical to physical in a separate >> hardware table). It'd be reasonable to ignore TLB0 for migration (treat >> it as invalidated), but not for debug since that may be where the >> translation we're interested in resides. > > Could we maybe add an ioctl that forces kvm to read out the current tlb0 contents and push them to memory? How slow would that be? Yes, I was thinking something like that. We'd just have to remove (make conditional on MMU type) the statement that this is synchronized implicitly on return from vcpu_run. Performance shouldn't be a problem -- we'd only need to sync once and then can do all the repeated debug accesses we want. So should be no need to mess around with partial sync. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RySX4-0006OK-JP for qemu-devel@nongnu.org; Fri, 17 Feb 2012 13:27:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RySX3-0004iC-CZ for qemu-devel@nongnu.org; Fri, 17 Feb 2012 13:27:46 -0500 Received: from tx2ehsobe002.messaging.microsoft.com ([65.55.88.12]:46277 helo=TX2EHSOBE005.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RySX3-0004i4-6v for qemu-devel@nongnu.org; Fri, 17 Feb 2012 13:27:45 -0500 Message-ID: <4F3E9C1B.5040404@freescale.com> Date: Fri, 17 Feb 2012 12:27:39 -0600 From: Scott Wood MIME-Version: 1.0 References: <4F2AB552.2070909@redhat.com> <4F2B41D6.8020603@codemonkey.ws> <51470503-DEE0-478D-8D01-020834AF6E8C@suse.de> <4F3117E5.6000105@redhat.com> <4F31241C.70404@redhat.com> <4F313354.4080401@redhat.com> <4B03190C-1B6B-48EC-92C7-C27F6982018A@suse.de> <4F3B9497.4020700@redhat.com> <4F3BB33C.1000908@redhat.com> <1FE08D00-49E8-4371-9F23-C5D2EE568FA8@suse.de> <4F3BB9DC.6040102@redhat.com> <3DC824A5-5D5A-4BCC-A0FB-1B459B7E362D@suse.de> <4F3D57E3.7020503@redhat.com> <810F6879-64A9-4FCF-9C22-00BCC945D6B0@suse.de> <4F3D5B35.4000606@redhat.com> <4F3D6A0E.4080705@freescale.com> <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> In-Reply-To: <016BCCE1-3E2C-4812-AA4D-2DC9D27CB457@suse.de> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Next gen kvm api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: KVM list , qemu-devel , kvm-ppc , linux-kernel , Avi Kivity On 02/16/2012 06:23 PM, Alexander Graf wrote: > On 16.02.2012, at 21:41, Scott Wood wrote: >> And yes, we do have fancier hardware coming fairly soon for which this >> breaks (TLB0 entries can be loaded without host involvement, as long as >> there's a translation from guest physical to physical in a separate >> hardware table). It'd be reasonable to ignore TLB0 for migration (treat >> it as invalidated), but not for debug since that may be where the >> translation we're interested in resides. > > Could we maybe add an ioctl that forces kvm to read out the current tlb0 contents and push them to memory? How slow would that be? Yes, I was thinking something like that. We'd just have to remove (make conditional on MMU type) the statement that this is synchronized implicitly on return from vcpu_run. Performance shouldn't be a problem -- we'd only need to sync once and then can do all the repeated debug accesses we want. So should be no need to mess around with partial sync. -Scott