From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) Date: Thu, 8 Aug 2013 12:29:07 -0700 Message-ID: <20130808192907.GA16694@cbox> References: <5203BF5D.4030007@suse.de> <20130808183935.GZ16694@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas =?iso-8859-1?Q?F=E4rber?= , quintela@redhat.com, qemu-devel , KVM devel mailing list , kvmarm@lists.cs.columbia.edu To: Peter Maydell Return-path: Received: from mail-pa0-f47.google.com ([209.85.220.47]:45395 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966204Ab3HHT3L (ORCPT ); Thu, 8 Aug 2013 15:29:11 -0400 Received: by mail-pa0-f47.google.com with SMTP id kl13so3887538pab.20 for ; Thu, 08 Aug 2013 12:29:11 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote: > On 8 August 2013 19:39, Christoffer Dall wrote: > > FWIW, from the kernel point of view I'd much prefer to return "this is > > the type of VCPU that I prefer to emulate" to user space on this current > > host than having QEMU come up with its own suggestion for CPU and asking > > the kernel for it. The reason is that it gives us slightly more freedom > > in how we choose to support a given host SoC in that we can say that we > > at least support core A on core B, so if user space can deal with a > > virtual core A, we should be good. > > Hmm, I'm not sure how useful a "query support" kind of API would > be to QEMU. QEMU is basically going to have two use cases: > (1) "I want an A15" [ie -cpu cortex-a15] > (2) "give me whatever you have and I'll cope" [ie -cpu host] > > so my thought was that we could just have the kernel support > init.target = KVM_ARM_TARGET_HOST; > memset(init.features, 0, sizeof(init.features)); > ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init); > > (in the same way we currently ask for KVM_ARM_TARGET_CORTEX_A15). > > I guess we could have a "return preferred target value" > VM ioctl, but it seems a bit pointless given that the > only thing userspace is going to do with the return > value is immediately feed it back to the kernel... > My thinking was that the result of cpu = KVM_ARM_TARGET_HOST would be the same as x = kvm_get_target_host(), cpu = x, but at the same time letting QEMU know what it's dealing with. Perhaps QEMU doesn't need this for emulation, but isn't it useful for save/restore/migration/debugging scenarios? So, if you just use the KVM_ARM_TARGET_HOST value, do you expect the kernel to just set the base address of the GIC interface, or? -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Vte-0000M0-0k for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7VtY-0003II-4g for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:29:17 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:63387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7VtX-0003GV-Uo for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:29:12 -0400 Received: by mail-pb0-f46.google.com with SMTP id rq2so3712770pbb.5 for ; Thu, 08 Aug 2013 12:29:11 -0700 (PDT) Date: Thu, 8 Aug 2013 12:29:07 -0700 From: Christoffer Dall Message-ID: <20130808192907.GA16694@cbox> References: <5203BF5D.4030007@suse.de> <20130808183935.GZ16694@cbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel , kvmarm@lists.cs.columbia.edu, Andreas =?iso-8859-1?Q?F=E4rber?= , KVM devel mailing list , quintela@redhat.com On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote: > On 8 August 2013 19:39, Christoffer Dall wrote: > > FWIW, from the kernel point of view I'd much prefer to return "this is > > the type of VCPU that I prefer to emulate" to user space on this current > > host than having QEMU come up with its own suggestion for CPU and asking > > the kernel for it. The reason is that it gives us slightly more freedom > > in how we choose to support a given host SoC in that we can say that we > > at least support core A on core B, so if user space can deal with a > > virtual core A, we should be good. > > Hmm, I'm not sure how useful a "query support" kind of API would > be to QEMU. QEMU is basically going to have two use cases: > (1) "I want an A15" [ie -cpu cortex-a15] > (2) "give me whatever you have and I'll cope" [ie -cpu host] > > so my thought was that we could just have the kernel support > init.target = KVM_ARM_TARGET_HOST; > memset(init.features, 0, sizeof(init.features)); > ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init); > > (in the same way we currently ask for KVM_ARM_TARGET_CORTEX_A15). > > I guess we could have a "return preferred target value" > VM ioctl, but it seems a bit pointless given that the > only thing userspace is going to do with the return > value is immediately feed it back to the kernel... > My thinking was that the result of cpu = KVM_ARM_TARGET_HOST would be the same as x = kvm_get_target_host(), cpu = x, but at the same time letting QEMU know what it's dealing with. Perhaps QEMU doesn't need this for emulation, but isn't it useful for save/restore/migration/debugging scenarios? So, if you just use the KVM_ARM_TARGET_HOST value, do you expect the kernel to just set the base address of the GIC interface, or? -Christoffer