All of lore.kernel.org
 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>,
	quintela@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	kvmarm@lists.cs.columbia.edu
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.

WARNING: multiple messages have this Message-ID (diff)
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: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08 12:51 -cpu host (was Re: [Qemu-devel] KVM call minutes for 2013-08-06) Peter Maydell
2013-08-08 12:51 ` [Qemu-devel] -cpu host (was " Peter Maydell
2013-08-08 15:55 ` Andreas Färber
2013-08-08 15:55   ` Andreas Färber
2013-08-08 18:20   ` Peter Maydell
2013-08-08 18:20     ` Peter Maydell
2013-08-08 18:39     ` Christoffer Dall
2013-08-08 18:39       ` Christoffer Dall
2013-08-08 19:05       ` Peter Maydell
2013-08-08 19:05         ` Peter Maydell
2013-08-08 19:29         ` Christoffer Dall
2013-08-08 19:29           ` Christoffer Dall
2013-08-08 20:48           ` Peter Maydell
2013-08-08 20:48             ` Peter Maydell
2013-08-08 20:57             ` Christoffer Dall
2013-08-08 20:57               ` Christoffer Dall
2013-08-08 21:16               ` Peter Maydell
2013-08-08 21:16                 ` Peter Maydell
2013-08-09 17:53           ` Eduardo Habkost
2013-08-09 17:53             ` Eduardo Habkost
2013-08-25 13:49             ` Gleb Natapov
2013-08-25 13:49               ` Gleb Natapov
2013-08-25 13:55     ` Gleb Natapov
2013-08-25 13:55       ` [Qemu-devel] " Gleb Natapov
2013-08-25 13:14   ` Gleb Natapov [this message]
2013-08-25 13:14     ` Gleb Natapov
2013-08-09 13:12 ` Peter Maydell
2013-08-09 20:07   ` Andreas Färber
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.