All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: mingo@redhat.com, tglx@linutronix.de, will@kernel.org,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/4] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute
Date: Wed, 8 Dec 2021 15:20:30 +0000	[thread overview]
Message-ID: <YbDNPrDOriI5FjfS@monolith.localdoman> (raw)
In-Reply-To: <87czm718cp.wl-maz@kernel.org>

Hi Marc,

On Wed, Dec 08, 2021 at 02:25:58PM +0000, Marc Zyngier wrote:
> On Wed, 08 Dec 2021 12:23:44 +0000,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > 
> > This makes me wonder. Should KVM enforce having userspace either not
> > setting the PMU for any VCPU, either setting it for all VCPUs? I think this
> > would be a good idea and will reduce complexity in the long run. I also
> > don't see a use case for userspace choosing to set the PMU for a subset of
> > VCPUs, leaving the other VCPUs with the default behaviour.
> 
> Indeed. As much as I'm happy to expose a PMU to a guest on an
> asymmetric system, I really do not want the asymmetry in the guest
> itself. So this should be an all or nothing behaviour.

From what I can tell, the only asymmetry that can be exposed to a guest as
a result of the series is the number of events supported on a VCPU.

I don't like the idea of forcing userspace to set the *same* PMU for all
VCPUs, as that would severely limit running VMs with PMU on asymmetric
systems.

Even if KVM forces to set a PMU (does not have to be the same PMU) for all
VCPUs, that still does not look like the correct solution for me, because
userspace can set PMUs with different number of events.

What I can try is to make kvm->arch.pmuver the minimum version of all the
VCPU PMUs and the implict PMU. I'll give that a go in the next iteration.

Thanks,
Alex

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Reiji Watanabe <reijiw@google.com>,
	james.morse@arm.com, suzuki.poulose@arm.com, will@kernel.org,
	mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, tglx@linutronix.de,
	mingo@redhat.com
Subject: Re: [PATCH v2 3/4] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute
Date: Wed, 8 Dec 2021 15:20:30 +0000	[thread overview]
Message-ID: <YbDNPrDOriI5FjfS@monolith.localdoman> (raw)
In-Reply-To: <87czm718cp.wl-maz@kernel.org>

Hi Marc,

On Wed, Dec 08, 2021 at 02:25:58PM +0000, Marc Zyngier wrote:
> On Wed, 08 Dec 2021 12:23:44 +0000,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > 
> > This makes me wonder. Should KVM enforce having userspace either not
> > setting the PMU for any VCPU, either setting it for all VCPUs? I think this
> > would be a good idea and will reduce complexity in the long run. I also
> > don't see a use case for userspace choosing to set the PMU for a subset of
> > VCPUs, leaving the other VCPUs with the default behaviour.
> 
> Indeed. As much as I'm happy to expose a PMU to a guest on an
> asymmetric system, I really do not want the asymmetry in the guest
> itself. So this should be an all or nothing behaviour.

From what I can tell, the only asymmetry that can be exposed to a guest as
a result of the series is the number of events supported on a VCPU.

I don't like the idea of forcing userspace to set the *same* PMU for all
VCPUs, as that would severely limit running VMs with PMU on asymmetric
systems.

Even if KVM forces to set a PMU (does not have to be the same PMU) for all
VCPUs, that still does not look like the correct solution for me, because
userspace can set PMUs with different number of events.

What I can try is to make kvm->arch.pmuver the minimum version of all the
VCPU PMUs and the implict PMU. I'll give that a go in the next iteration.

Thanks,
Alex

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-12-08 15:20 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 17:02 [PATCH v2 0/4] KVM: arm64: Improve PMU support on heterogeneous systems Alexandru Elisei
2021-12-06 17:02 ` Alexandru Elisei
2021-12-06 17:02 ` [PATCH v2 1/4] perf: Fix wrong name in comment for struct perf_cpu_context Alexandru Elisei
2021-12-06 17:02   ` Alexandru Elisei
2021-12-06 17:02 ` [PATCH v2 2/4] KVM: arm64: Keep a list of probed PMUs Alexandru Elisei
2021-12-06 17:02   ` Alexandru Elisei
2021-12-06 17:02 ` [PATCH v2 3/4] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute Alexandru Elisei
2021-12-06 17:02   ` Alexandru Elisei
2021-12-08  3:13   ` Reiji Watanabe
2021-12-08  3:13     ` Reiji Watanabe
2021-12-08 12:23     ` Alexandru Elisei
2021-12-08 12:23       ` Alexandru Elisei
2021-12-08 12:43       ` Alexandru Elisei
2021-12-08 12:43         ` Alexandru Elisei
2021-12-08 14:25       ` Marc Zyngier
2021-12-08 14:25         ` Marc Zyngier
2021-12-08 15:20         ` Alexandru Elisei [this message]
2021-12-08 15:20           ` Alexandru Elisei
2021-12-08 15:44           ` Marc Zyngier
2021-12-08 15:44             ` Marc Zyngier
2021-12-08 16:11             ` Alexandru Elisei
2021-12-08 16:11               ` Alexandru Elisei
2021-12-08 16:21               ` Marc Zyngier
2021-12-08 16:21                 ` Marc Zyngier
2021-12-06 17:02 ` [PATCH v2 4/4] KVM: arm64: Refuse to run VCPU if the PMU doesn't match the physical CPU Alexandru Elisei
2021-12-06 17:02   ` Alexandru Elisei
2021-12-07 14:17   ` Alexandru Elisei
2021-12-07 14:17     ` Alexandru Elisei
2021-12-08  7:54     ` Reiji Watanabe
2021-12-08  7:54       ` Reiji Watanabe
2021-12-08 10:38       ` Alexandru Elisei
2021-12-08 10:38         ` Alexandru Elisei
2021-12-13  7:40         ` Reiji Watanabe
2021-12-13  7:40           ` Reiji Watanabe
2021-12-08  9:56     ` Marc Zyngier
2021-12-08  9:56       ` Marc Zyngier
2021-12-08 11:18       ` Alexandru Elisei
2021-12-08 11:18         ` Alexandru Elisei
2021-12-08  2:36 ` [PATCH v2 0/4] KVM: arm64: Improve PMU support on heterogeneous systems Reiji Watanabe
2021-12-08  2:36   ` Reiji Watanabe
2021-12-08  8:05   ` Marc Zyngier
2021-12-08  8:05     ` Marc Zyngier
2021-12-13  6:36     ` Reiji Watanabe
2021-12-13  6:36       ` Reiji Watanabe
2021-12-13 11:14       ` Alexandru Elisei
2021-12-13 11:14         ` Alexandru Elisei
2021-12-14  6:24         ` Reiji Watanabe
2021-12-14  6:24           ` Reiji Watanabe
2021-12-14 11:56           ` Marc Zyngier
2021-12-14 11:56             ` Marc Zyngier
2021-12-15  6:47             ` Reiji Watanabe
2021-12-15  6:47               ` Reiji Watanabe

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=YbDNPrDOriI5FjfS@monolith.localdoman \
    --to=alexandru.elisei@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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.