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?
next prev parent 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).