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: Mon, 7 Feb 2011 12:52:16 -0600 Message-ID: <20110207125216.35c5862a@udp111988uds> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <9F6FE96B71CF29479FF1CDC8046E15030C14EF@039-SN1MPN1-002.039d.mgd.msft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Yoder Stuart-B08248 , Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: Alexander Graf Return-path: Received: from am1ehsobe005.messaging.microsoft.com ([213.199.154.208]:19402 "EHLO AM1EHSOBE005.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754600Ab1BGSwf (ORCPT ); Mon, 7 Feb 2011 13:52:35 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 7 Feb 2011 17:49:51 +0100 Alexander Graf wrote: > > On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote: > > > Suggested change to this would be to have Qemu set tlb_type as > > an _input_ argument. If KVM supports it, that type gets used, > > else an error is returned. This would allow Qemu to tell > > the kernel what type of MMU it is prepared to support. Without > > this Qemu would just have to error out if the type returned is > > unknown. > > Yes, we could use the same struct for get and set. On set, it could transfer the mmu type, on get it could tell userspace the mmu type. What happens if a get is done before the first set, and there are multiple MMU type options for this hardware, with differing entry sizes? Qemu would have to know beforehand how large to make the buffer. We could say that going forward, it's expected that qemu will do a TLB set (either a full one, or a lightweight alternative) after creating a vcpu. For compatibility, if this doesn't happen before the vcpu is run, the TLB is created and initialized as it is today, but no new Qemu-visible features will be enabled that way. If Qemu does a get without ever doing some set operation, it should get an error, since the requirement to do a set is added at the same time as the get API. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41737 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmYKr-0000Iz-WC for qemu-devel@nongnu.org; Mon, 07 Feb 2011 16:09:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmWCS-0000tk-5V for qemu-devel@nongnu.org; Mon, 07 Feb 2011 13:52:37 -0500 Received: from am1ehsobe005.messaging.microsoft.com ([213.199.154.208]:19398 helo=AM1EHSOBE005.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmWCR-0000tf-PX for qemu-devel@nongnu.org; Mon, 07 Feb 2011 13:52:36 -0500 Date: Mon, 7 Feb 2011 12:52:16 -0600 From: Scott Wood Message-ID: <20110207125216.35c5862a@udp111988uds> In-Reply-To: References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <9F6FE96B71CF29479FF1CDC8046E15030C14EF@039-SN1MPN1-002.039d.mgd.msft.net> 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: "qemu-devel@nongnu.org" , Yoder Stuart-B08248 , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , Wood Scott-B07421 On Mon, 7 Feb 2011 17:49:51 +0100 Alexander Graf wrote: > > On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote: > > > Suggested change to this would be to have Qemu set tlb_type as > > an _input_ argument. If KVM supports it, that type gets used, > > else an error is returned. This would allow Qemu to tell > > the kernel what type of MMU it is prepared to support. Without > > this Qemu would just have to error out if the type returned is > > unknown. > > Yes, we could use the same struct for get and set. On set, it could transfer the mmu type, on get it could tell userspace the mmu type. What happens if a get is done before the first set, and there are multiple MMU type options for this hardware, with differing entry sizes? Qemu would have to know beforehand how large to make the buffer. We could say that going forward, it's expected that qemu will do a TLB set (either a full one, or a lightweight alternative) after creating a vcpu. For compatibility, if this doesn't happen before the vcpu is run, the TLB is created and initialized as it is today, but no new Qemu-visible features will be enabled that way. If Qemu does a get without ever doing some set operation, it should get an error, since the requirement to do a set is added at the same time as the get API. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 07 Feb 2011 18:52:16 +0000 Subject: Re: RFC: New API for PPC for vcpu mmu access Message-Id: <20110207125216.35c5862a@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> <9F6FE96B71CF29479FF1CDC8046E15030C14EF@039-SN1MPN1-002.039d.mgd.msft.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Yoder Stuart-B08248 , Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" On Mon, 7 Feb 2011 17:49:51 +0100 Alexander Graf wrote: > > On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote: > > > Suggested change to this would be to have Qemu set tlb_type as > > an _input_ argument. If KVM supports it, that type gets used, > > else an error is returned. This would allow Qemu to tell > > the kernel what type of MMU it is prepared to support. Without > > this Qemu would just have to error out if the type returned is > > unknown. > > Yes, we could use the same struct for get and set. On set, it could transfer the mmu type, on get it could tell userspace the mmu type. What happens if a get is done before the first set, and there are multiple MMU type options for this hardware, with differing entry sizes? Qemu would have to know beforehand how large to make the buffer. We could say that going forward, it's expected that qemu will do a TLB set (either a full one, or a lightweight alternative) after creating a vcpu. For compatibility, if this doesn't happen before the vcpu is run, the TLB is created and initialized as it is today, but no new Qemu-visible features will be enabled that way. If Qemu does a get without ever doing some set operation, it should get an error, since the requirement to do a set is added at the same time as the get API. -Scott