From: Gleb Natapov <gleb@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
kvmarm@lists.cs.columbia.edu, qemu-devel <qemu-devel@nongnu.org>,
KVM devel mailing list <kvm@vger.kernel.org>,
quintela@redhat.com
Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
Date: Sun, 25 Aug 2013 16:14:54 +0300 [thread overview]
Message-ID: <20130825131454.GQ8218@redhat.com> (raw)
In-Reply-To: <5203BF5D.4030007@suse.de>
On Thu, Aug 08, 2013 at 05:55:09PM +0200, Andreas Färber wrote:
> Hi Peter,
>
> Am 08.08.2013 14:51, schrieb Peter Maydell:
> > [I missed this KVM call but the stuff about -cpu host ties into
> > an issue we've been grappling with for ARM KVM, so it seems
> > a reasonable jumping-off-point.]
> >
> > On 6 August 2013 16:15, Juan Quintela <quintela@redhat.com> wrote:
> >> 2013-08-06
> >> ----------
> >>
> >> What libvirt needs/miss Today?
> >> - how to handle machine types? creating them inside qemu?
> >> - qemu --cpu help
> >> only shows cpus, not what features qemu will use
> >> - qemu -cpu host
> >> what does this exactly means? kvm removes same flags.
> >> - Important to know if migration would work.
> >> - Machine types sometimes disable some feature, so cpu alone is not
> >> enough.
> >
> >> - kernel removes some features because it knows it can't be virtualised
> >> - qemu adds some others because it knows it don't need host support
> >> - and then lots of features in the middle
> >
> > So, coming at this from an ARM perspective:
> > Should any target arch that supports KVM also support "-cpu host"?
> > If so, what should it do?
>
> I think that depends on the target and whether/what is useful.
>
> > Is there a description somewhere of
> > what the x86 and PPC semantics of -cpu host are?
>
> I'm afraid our usual documentation will be reading the source code. ;)
>
> x86 was first to implement -cpu host and passed through pretty much all
> host features even if they would not work without additional support
> code.
This is definitely not true. Only features that will work are passsed through.
Actually the definition of "-cpu host" for x86 can be: advertise any
feature that can be supported on this host/qemu combo.
> I've seen a bunch of bugs where that leads to GMP and others
> breaking badly. Lately in the case of PMU we've started to limit that.
The problem with PMU was that PMU capabilities was passed through even
for non "-cpu host". There was no problem with "-cpu host".
> Alex proposed -cpu best, which was never merged to date. It was similar
> to how ppc's -cpu host works:
According to http://wiki.qemu.org/Features/CPUModels#-cpu_host_vs_-cpu_best
it should select predefined cpu model closest to host one. Useful, bit
not the same as "-cpu host".
>
> ppc matches the Processor Version Register (PVR) in kvm.c against its
> known models from cpu-models.c (strictly today, mask being discussed).
> The PVR can be read from userspace via mfpvr alias to mfspr (Move From
> Special Purpose Register; possibly emulated for userspace by kernel?).
> CPU features are all QEMU-driven AFAIU, through the "CPU families" in
> translate_init.c. Beware, everything is highly macro'fied in ppc code.
>
--
Gleb.
next prev parent reply other threads:[~2013-08-25 13:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 12:51 [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) Peter Maydell
2013-08-08 15:55 ` Andreas Färber
2013-08-08 18:20 ` Peter Maydell
2013-08-08 18:39 ` Christoffer Dall
2013-08-08 19:05 ` Peter Maydell
2013-08-08 19:29 ` Christoffer Dall
2013-08-08 20:48 ` Peter Maydell
2013-08-08 20:57 ` Christoffer Dall
2013-08-08 21:16 ` Peter Maydell
2013-08-09 17:53 ` Eduardo Habkost
2013-08-25 13:49 ` Gleb Natapov
2013-08-25 13:55 ` Gleb Natapov
2013-08-25 13:14 ` Gleb Natapov [this message]
2013-08-09 13:12 ` Peter Maydell
2013-08-09 20:07 ` Andreas Färber
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=20130825131454.GQ8218@redhat.com \
--to=gleb@redhat.com \
--cc=afaerber@suse.de \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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).