From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9f39-0006EW-7x for qemu-devel@nongnu.org; Wed, 14 Aug 2013 13:40:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9f33-0007wl-6V for qemu-devel@nongnu.org; Wed, 14 Aug 2013 13:39:59 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:40302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9f33-0007wb-0T for qemu-devel@nongnu.org; Wed, 14 Aug 2013 13:39:53 -0400 Received: by mail-pd0-f179.google.com with SMTP id v10so6746541pde.10 for ; Wed, 14 Aug 2013 10:39:52 -0700 (PDT) Date: Wed, 14 Aug 2013 10:39:49 -0700 From: Christoffer Dall Message-ID: <20130814173949.GF11390@cbox> References: <831e8e0f45afcdb8a141a9b9e89fad03@www.loen.fr> <36EAA81C-38E0-46DA-9B58-284495B69E74@suse.de> <8B645B6D-9427-4784-95E1-6B0D17932F06@suse.de> <20130814172604.GC11390@cbox> <04BA3443-74C6-47B9-AABD-30DC200A95A8@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04BA3443-74C6-47B9-AABD-30DC200A95A8@suse.de> Subject: Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , patches@linaro.org, qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= , kvmarm@lists.cs.columbia.edu On Wed, Aug 14, 2013 at 07:31:59PM +0200, Alexander Graf wrote: > > On 14.08.2013, at 19:26, Christoffer Dall wrote: > > > On Wed, Aug 14, 2013 at 11:30:46AM +0200, Alexander Graf wrote: > >> > >> On 14.08.2013, at 11:23, Peter Maydell wrote: > >> > >>> On 14 August 2013 10:11, Alexander Graf wrote: > >>>> You're right, the main difference is that KVM doesn't have any > >>>> idea what a "host" style CPU is. It only knows how to report to QEMU > >>>> what the current host CPU would be, so that anything from VCPU_INIT > >>>> onwards is 100% identical regardless of whether the user said > >>>> -cpu host or -cpu xxx. > >>>> > >>>> I'm still puzzled on how this will work with BIG.little btw. > >>> > >>> The rough idea is that for BIG.little the kernel must trap the > >>> ID registers at least (so that the vcpu seems consistent to the > >>> guest whether it's running on the big or the little core). For > >>> "-cpu host" the guest would see whatever is the most low-overhead > >>> for the kernel to provide (ie assuming the big and little CPUs > >>> are roughly-similar you could make -cpu host provide something > >>> that looks to the guest like the big CPU and don't have to trap > >>> quite as much as you would for providing a vcpu that wasn't the > >>> same as either the big or little one). > >> > >> So -cpu host in this case wouldn't actually expose the host CPU 1:1, but instead a cortex-a15 even when it's run on an a7 BIG.little core. I see. > >> > > Yes, from the discussion we've had the whole picture just becomes to > > blurry when you start presenting multiple different CPUs to the guest > > and there's really no need to that I'm aware of. > > > > In fact the -cpu host case fits quite nicely with this state of mind; > > the kernel is free to decide based on the specific hardware and config > > on which it's running how to handle VMs on BL. > > So why not have a vm ioctl to fetch the "best match" vcpu type? I don't like the idea of adding any awareness of a "host" type to the normal vcpu creation process. > > That's actually what I suggested initially. I'm not really a QEMU expert, but I think Peter already answered this question: he doesn't want to support hundreds of CPU models in QEMU just to be able to run KVM when it's not necessary. If his argument holds in that you can support -cpu host without having a model for that specific cpu in QEMU, then indeed it is a strong argument, and we have the problem with ARMv8 already, and this goes a long way to solve that. No?