All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: peter.maydell@linaro.org, qemu-arm@nongnu.org,
	qemu-devel@nongnu.org, shannon.zhao@linaro.org
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
Date: Mon, 01 Aug 2016 15:26:59 +0200	[thread overview]
Message-ID: <1470058019.3971.13.camel@redhat.com> (raw)
In-Reply-To: <20160801130808.2igpsx52opi7ogvk@kamzik.localdomain>

On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
> > I'm not sure a warning is enough: if I start a guest and
> > explicitly ask for a PMU, I expect it to be there, or for
> > the guest not to start at all. How does x86 behave in this
> > regard?
> 
> Peter had a good suggestion for this. We need to wrap the property
> addition in an arm_feature check like the has_el3 property. That will
> remove it from all cpu types that don't support it.

Wouldn't that mean that you'd be unable to use

  -cpu foo,pmu=off

if CPU model 'foo' doesn't support a PMU? I'd expect that
to work.

I've played around with this a bit on x86 and it doesn't
look like it necessarily behaves the way I'd expect it to,
either, so maybe this is just a case of my expectations
being unreasonable? :)

-- 
Andrea Bolognani / Red Hat / Virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Bolognani <abologna@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Wei Huang <wei@redhat.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org,
	peter.maydell@linaro.org, shannon.zhao@linaro.org
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
Date: Mon, 01 Aug 2016 15:26:59 +0200	[thread overview]
Message-ID: <1470058019.3971.13.camel@redhat.com> (raw)
In-Reply-To: <20160801130808.2igpsx52opi7ogvk@kamzik.localdomain>

On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
> > I'm not sure a warning is enough: if I start a guest and
> > explicitly ask for a PMU, I expect it to be there, or for
> > the guest not to start at all. How does x86 behave in this
> > regard?
> 
> Peter had a good suggestion for this. We need to wrap the property
> addition in an arm_feature check like the has_el3 property. That will
> remove it from all cpu types that don't support it.

Wouldn't that mean that you'd be unable to use

  -cpu foo,pmu=off

if CPU model 'foo' doesn't support a PMU? I'd expect that
to work.

I've played around with this a bit on x86 and it doesn't
look like it necessarily behaves the way I'd expect it to,
either, so maybe this is just a case of my expectations
being unreasonable? :)

-- 
Andrea Bolognani / Red Hat / Virtualization

  parent reply	other threads:[~2016-08-01 13:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-28 16:38 [Qemu-arm] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support Wei Huang
2016-07-28 16:38 ` [Qemu-devel] " Wei Huang
2016-07-29  0:59 ` [Qemu-arm] " Shannon Zhao
2016-07-29  0:59   ` Shannon Zhao
2016-07-29  6:54 ` [Qemu-arm] " Andrew Jones
2016-07-29  6:54   ` Andrew Jones
2016-07-29 15:07   ` [Qemu-arm] " Wei Huang
2016-07-29 15:07     ` Wei Huang
2016-07-29 15:29   ` [Qemu-arm] " Peter Maydell
2016-07-29 15:29     ` Peter Maydell
2016-08-01 12:04   ` [Qemu-arm] " Andrea Bolognani
2016-08-01 12:04     ` Andrea Bolognani
2016-08-01 13:08     ` [Qemu-arm] " Andrew Jones
2016-08-01 13:08       ` Andrew Jones
2016-08-01 13:16       ` [Qemu-arm] " Peter Maydell
2016-08-01 13:16         ` Peter Maydell
2016-08-01 13:26       ` Andrea Bolognani [this message]
2016-08-01 13:26         ` Andrea Bolognani
2016-08-01 13:32         ` [Qemu-arm] " Peter Maydell
2016-08-01 13:32           ` Peter Maydell
2016-08-01 14:55           ` [Qemu-arm] " Andrea Bolognani
2016-08-01 14:55             ` Andrea Bolognani
2016-08-13  6:06           ` [Qemu-arm] " Wei Huang
2016-08-13  6:06             ` Wei Huang
2016-08-15  9:24             ` [Qemu-arm] " Andrea Bolognani
2016-08-15  9:24               ` Andrea Bolognani
2016-07-29  7:57 ` [Qemu-arm] " Peter Maydell
2016-07-29  7:57   ` [Qemu-devel] " Peter Maydell
2016-07-29 15:08   ` [Qemu-arm] " Wei Huang
2016-07-29 15:08     ` [Qemu-devel] " Wei Huang
2016-07-29 15:25     ` [Qemu-arm] " Peter Maydell
2016-07-29 15:25       ` [Qemu-devel] " 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=1470058019.3971.13.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shannon.zhao@linaro.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 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.