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:26:04 -0700	[thread overview]
Message-ID: <20130814172604.GC11390@cbox> (raw)
In-Reply-To: <8B645B6D-9427-4784-95E1-6B0D17932F06@suse.de>

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.

-Christoffer

  reply	other threads:[~2013-08-14 17:26 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 [this message]
2013-08-14 17:31                     ` Alexander Graf
2013-08-14 17:39                       ` Christoffer Dall
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=20130814172604.GC11390@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).