All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: will@kernel.org, catalin.marinas@arm.com,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 3/4] KVM: arm64: Pass pmu events to hyp via vcpu
Date: Tue, 10 May 2022 10:21:00 +0100	[thread overview]
Message-ID: <87bkw57ngj.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTyq_T8x35hjWZgvk+Am3em172EeYigAiBfqvL2L7KodBg@mail.gmail.com>

On Tue, 10 May 2022 07:43:45 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Oliver,
> 
> 
> On Mon, May 9, 2022 at 9:21 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Mon, May 09, 2022 at 12:03:29PM +0000, Fuad Tabba wrote:
> > > Instead of the host accessing hyp data directly, pass the pmu
> > > events of the current cpu to hyp via the vcpu.
> > >
> > > This adds 64 bits (in two fields) to the vcpu that need to be
> > > synced before every vcpu run in nvhe and protected modes.
> > > However, it isolates the hypervisor from the host, which allows
> > > us to use pmu in protected mode in a subsequent patch.
> > >
> > > No visible side effects in behavior intended.
> > >
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > >  arch/arm64/include/asm/kvm_host.h |  8 ++------
> > >  arch/arm64/kvm/arm.c              | 15 +++++++++++++++
> > >  arch/arm64/kvm/hyp/nvhe/switch.c  | 20 ++++++--------------
> > >  arch/arm64/kvm/pmu.c              | 12 ++++--------
> > >  include/kvm/arm_pmu.h             |  6 ++++++
> > >  5 files changed, 33 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index dfd360404dd8..90476e713643 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -273,14 +273,8 @@ struct kvm_cpu_context {
> > >       struct kvm_vcpu *__hyp_running_vcpu;
> > >  };
> > >
> > > -struct kvm_pmu_events {
> > > -     u32 events_host;
> > > -     u32 events_guest;
> > > -};
> > > -
> >
> > Looks like you're moving this to arm_pmu.h as well. Probably a better
> > home for it, but unclear why it is done in this patch.
> 
> Like you said, I thought it was a better home, and it's not needed
> here anymore. I could maybe move it to the repacking patch and make it
> as a general "cleanup" patch, if you think that would be clearer.
> >
> > >  struct kvm_host_data {
> > >       struct kvm_cpu_context host_ctxt;
> > > -     struct kvm_pmu_events pmu_events;
> > >  };
> > >
> >
> > Are we going to need this struct any more since it now has a single
> > member?
> 
> I thought about removing it, but it would cause a bit of code churn.
> That said, I could remove it in a new patch that I have as the last
> one, and leave it to the maintainer to decide whether to take it.

Unless there is a compelling reason for getting rid of kvm_host_data,
I'd keep it. Because next thing you know, we'll need another bit in
there, and we'll reintroduce it. This costs us nothing, so let's not
worry about it.

> 
> >
> > >  struct kvm_host_psci_config {
> > > @@ -763,6 +757,7 @@ void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > >  struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> > >
> > >  DECLARE_KVM_HYP_PER_CPU(struct kvm_host_data, kvm_host_data);
> > > +DECLARE_PER_CPU(struct kvm_pmu_events, kvm_pmu_events);
> >
> > Why do you need this declaration? I don't see the percpu data being
> > accessed outside of pmu.c.
> 
> You're right. At one previous iteration I did need it, which is why
> it's here, but not anymore. Will remove it.

And then make the definition static?

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: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Oliver Upton <oupton@google.com>,
	kvmarm@lists.cs.columbia.edu, kernel-team@android.com,
	catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 3/4] KVM: arm64: Pass pmu events to hyp via vcpu
Date: Tue, 10 May 2022 10:21:00 +0100	[thread overview]
Message-ID: <87bkw57ngj.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTyq_T8x35hjWZgvk+Am3em172EeYigAiBfqvL2L7KodBg@mail.gmail.com>

On Tue, 10 May 2022 07:43:45 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Oliver,
> 
> 
> On Mon, May 9, 2022 at 9:21 PM Oliver Upton <oupton@google.com> wrote:
> >
> > On Mon, May 09, 2022 at 12:03:29PM +0000, Fuad Tabba wrote:
> > > Instead of the host accessing hyp data directly, pass the pmu
> > > events of the current cpu to hyp via the vcpu.
> > >
> > > This adds 64 bits (in two fields) to the vcpu that need to be
> > > synced before every vcpu run in nvhe and protected modes.
> > > However, it isolates the hypervisor from the host, which allows
> > > us to use pmu in protected mode in a subsequent patch.
> > >
> > > No visible side effects in behavior intended.
> > >
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > >  arch/arm64/include/asm/kvm_host.h |  8 ++------
> > >  arch/arm64/kvm/arm.c              | 15 +++++++++++++++
> > >  arch/arm64/kvm/hyp/nvhe/switch.c  | 20 ++++++--------------
> > >  arch/arm64/kvm/pmu.c              | 12 ++++--------
> > >  include/kvm/arm_pmu.h             |  6 ++++++
> > >  5 files changed, 33 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index dfd360404dd8..90476e713643 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -273,14 +273,8 @@ struct kvm_cpu_context {
> > >       struct kvm_vcpu *__hyp_running_vcpu;
> > >  };
> > >
> > > -struct kvm_pmu_events {
> > > -     u32 events_host;
> > > -     u32 events_guest;
> > > -};
> > > -
> >
> > Looks like you're moving this to arm_pmu.h as well. Probably a better
> > home for it, but unclear why it is done in this patch.
> 
> Like you said, I thought it was a better home, and it's not needed
> here anymore. I could maybe move it to the repacking patch and make it
> as a general "cleanup" patch, if you think that would be clearer.
> >
> > >  struct kvm_host_data {
> > >       struct kvm_cpu_context host_ctxt;
> > > -     struct kvm_pmu_events pmu_events;
> > >  };
> > >
> >
> > Are we going to need this struct any more since it now has a single
> > member?
> 
> I thought about removing it, but it would cause a bit of code churn.
> That said, I could remove it in a new patch that I have as the last
> one, and leave it to the maintainer to decide whether to take it.

Unless there is a compelling reason for getting rid of kvm_host_data,
I'd keep it. Because next thing you know, we'll need another bit in
there, and we'll reintroduce it. This costs us nothing, so let's not
worry about it.

> 
> >
> > >  struct kvm_host_psci_config {
> > > @@ -763,6 +757,7 @@ void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > >  struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> > >
> > >  DECLARE_KVM_HYP_PER_CPU(struct kvm_host_data, kvm_host_data);
> > > +DECLARE_PER_CPU(struct kvm_pmu_events, kvm_pmu_events);
> >
> > Why do you need this declaration? I don't see the percpu data being
> > accessed outside of pmu.c.
> 
> You're right. At one previous iteration I did need it, which is why
> it's here, but not anymore. Will remove it.

And then make the definition static?

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:[~2022-05-10  9:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 12:03 [PATCH v3 0/4] KVM: arm64: Do not communicate host pmu event changes by accessing hyp data Fuad Tabba
2022-05-09 12:03 ` Fuad Tabba
2022-05-09 12:03 ` [PATCH v3 1/4] KVM: arm64: Wrapper for getting pmu_events Fuad Tabba
2022-05-09 12:03   ` Fuad Tabba
2022-05-09 19:41   ` Oliver Upton
2022-05-09 19:41     ` Oliver Upton
2022-05-09 12:03 ` [PATCH v3 2/4] KVM: arm64: Repack struct kvm_pmu to reduce size Fuad Tabba
2022-05-09 12:03   ` Fuad Tabba
2022-05-09 19:57   ` Oliver Upton
2022-05-09 19:57     ` Oliver Upton
2022-05-10  6:38     ` Fuad Tabba
2022-05-10  6:38       ` Fuad Tabba
2022-05-09 12:03 ` [PATCH v3 3/4] KVM: arm64: Pass pmu events to hyp via vcpu Fuad Tabba
2022-05-09 12:03   ` Fuad Tabba
2022-05-09 20:21   ` Oliver Upton
2022-05-09 20:21     ` Oliver Upton
2022-05-10  6:43     ` Fuad Tabba
2022-05-10  6:43       ` Fuad Tabba
2022-05-10  9:21       ` Marc Zyngier [this message]
2022-05-10  9:21         ` Marc Zyngier
2022-05-09 12:03 ` [PATCH v3 4/4] KVM: arm64: Reenable pmu in Protected Mode Fuad Tabba
2022-05-09 12:03   ` Fuad Tabba
2022-05-09 22:36   ` Oliver Upton
2022-05-09 22:36     ` Oliver Upton
2022-05-10  6:45     ` Fuad Tabba
2022-05-10  6:45       ` Fuad Tabba

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=87bkw57ngj.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=tabba@google.com \
    --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.