qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	patches@linaro.org, qemu-devel@nongnu.org,
	"Andreas Färber" <afaerber@suse.de>,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM
Date: Wed, 14 Aug 2013 10:39:49 -0700	[thread overview]
Message-ID: <20130814173949.GF11390@cbox> (raw)
In-Reply-To: <04BA3443-74C6-47B9-AABD-30DC200A95A8@suse.de>

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 <agraf@suse.de> 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?

  reply	other threads:[~2013-08-14 17:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 18:03 [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM Peter Maydell
2013-08-13 18:03 ` [Qemu-devel] [RFC 1/2] target-arm: Don't hardcode KVM target CPU to be A15 Peter Maydell
2013-08-13 18:03 ` [Qemu-devel] [RFC 2/2] target-arm: Provide '-cpu host' when running KVM Peter Maydell
2013-08-14  6:32 ` [Qemu-devel] [RFC 0/2] " Alexander Graf
2013-08-14  8:11   ` Marc Zyngier
2013-08-14  8:16     ` Alexander Graf
2013-08-14  8:27       ` Marc Zyngier
2013-08-14  8:46         ` Alexander Graf
2013-08-14  9:07           ` Peter Maydell
2013-08-14  9:11             ` Alexander Graf
2013-08-14  9:23               ` Peter Maydell
2013-08-14  9:30                 ` Alexander Graf
2013-08-14 17:26                   ` Christoffer Dall
2013-08-14 17:31                     ` Alexander Graf
2013-08-14 17:39                       ` Christoffer Dall [this message]
2013-08-14 17:44                         ` Alexander Graf
2013-08-14 18:18                           ` Christoffer Dall
2013-08-14 18:21                             ` Alexander Graf
2013-08-14 18:27                               ` Peter Maydell
2013-08-14 19:23                                 ` Alexander Graf
2013-08-14 18:28                               ` Christoffer Dall
2013-08-14 19:28                                 ` Alexander Graf
2013-08-14 20:33                                   ` Christoffer Dall
2013-08-14 20:47                                     ` Alexander Graf
2013-08-14 20:56                                       ` Christoffer Dall
2013-08-14 21:00                                         ` Alexander Graf
2013-08-25 14:42                                   ` Gleb Natapov
2013-08-25 15:11                                     ` Peter Maydell
2013-08-26 11:18                                       ` Gleb Natapov
2013-08-26 12:17                                         ` Peter Maydell
2013-08-14 18:11                       ` Peter Maydell
2013-08-14 18:15                         ` Alexander Graf
2013-08-14 18:24                           ` Peter Maydell
2013-08-14  9:06   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130814173949.GF11390@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).