From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Maydell Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) Date: Thu, 8 Aug 2013 20:05:11 +0100 Message-ID: References: <5203BF5D.4030007@suse.de> <20130808183935.GZ16694@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Andreas_F=C3=A4rber?= , quintela@redhat.com, qemu-devel , KVM devel mailing list , kvmarm@lists.cs.columbia.edu To: Christoffer Dall Return-path: Received: from mail-lb0-f179.google.com ([209.85.217.179]:40879 "EHLO mail-lb0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752450Ab3HHTFd (ORCPT ); Thu, 8 Aug 2013 15:05:33 -0400 Received: by mail-lb0-f179.google.com with SMTP id v1so2694451lbd.38 for ; Thu, 08 Aug 2013 12:05:31 -0700 (PDT) In-Reply-To: <20130808183935.GZ16694@cbox> Sender: kvm-owner@vger.kernel.org List-ID: 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... -- PMM From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7VWn-0006en-6t for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:05:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7VWe-0002LA-TD for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:05:41 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:38321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7VWe-0002L0-IR for qemu-devel@nongnu.org; Thu, 08 Aug 2013 15:05:32 -0400 Received: by mail-lb0-f180.google.com with SMTP id a16so2725634lbj.39 for ; Thu, 08 Aug 2013 12:05:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130808183935.GZ16694@cbox> References: <5203BF5D.4030007@suse.de> <20130808183935.GZ16694@cbox> From: Peter Maydell Date: Thu, 8 Aug 2013 20:05:11 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Christoffer Dall Cc: qemu-devel , kvmarm@lists.cs.columbia.edu, =?UTF-8?Q?Andreas_F=C3=A4rber?= , KVM devel mailing list , quintela@redhat.com 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... -- PMM