qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

  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).