public inbox for kvmarm@lists.cs.columbia.edu
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>,
	Christoffer Dall <cdall@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 16/16] KVM: arm64/sve: Report and enable SVE API extensions for userspace
Date: Thu, 26 Jul 2018 14:23:07 +0100	[thread overview]
Message-ID: <20180726132307.GY4240@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20180719152420.mvzd5zjkm47ujdlj@kamzik.brq.redhat.com>

On Thu, Jul 19, 2018 at 05:24:20PM +0200, Andrew Jones wrote:
> On Thu, Jun 21, 2018 at 03:57:40PM +0100, Dave Martin wrote:
> > This patch reports the availability of KVM SVE support to userspace
> > via a new vcpu feature flag KVM_ARM_VCPU_SVE.  This flag is
> > reported via the KVM_ARM_PREFERRED_TARGET ioctl.
> > 
> > Userspace can enable the feature by setting the flag for
> > KVM_ARM_VCPU_INIT.  Without this flag set, SVE-related ioctls and
> > register access extensions are hidden, and SVE remains disabled
> > unconditionally for the guest.  This ensures that non-SVE-aware KVM
> > userspace does not receive a vcpu that it does not understand how
> > to snapshot or restore correctly.
> > 
> > Storage is allocated for the SVE register state at vcpu init time,
> > sufficient for the maximum vector length to be exposed to the vcpu.
> > No attempt is made to allocate the storage lazily for now.  Also,
> > no attempt is made to resize the storage dynamically, since the
> > effective vector length of the vcpu can change at each EL0/EL1
> > transition.  The storage is freed at the vcpu uninit hook.
> > 
> > No particular attempt is made to prevent userspace from creating a
> > mix of vcpus some of which have SVE enabled and some of which have
> > it disabled.  This may or may not be useful, but it reflects the
> > underlying architectural behaviour.
> > 
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > ---
> >  arch/arm64/include/asm/kvm_host.h |  6 +++---
> >  arch/arm64/include/uapi/asm/kvm.h |  1 +
> >  arch/arm64/kvm/guest.c            | 19 +++++++++++++------
> >  arch/arm64/kvm/reset.c            | 14 ++++++++++++++
> >  4 files changed, 31 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index d2084ae..d956cf2 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -44,7 +44,7 @@
> >  
> >  #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
> >  
> > -#define KVM_VCPU_MAX_FEATURES 4
> > +#define KVM_VCPU_MAX_FEATURES 5
> >  
> >  #define KVM_REQ_SLEEP \
> >  	KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> > @@ -439,8 +439,8 @@ static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> >  static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> >  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
> >  
> > -static inline int kvm_arm_arch_vcpu_init(struct kvm_vcpu *vcpu) { return 0; }
> > -static inline void kvm_arm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> > +int kvm_arm_arch_vcpu_init(struct kvm_vcpu *vcpu);
> > +void kvm_arm_arch_vcpu_uninit(struct kvm_vcpu *vcpu);
> >  
> >  void kvm_arm_init_debug(void);
> >  void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index f54a9b0..6acf276 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -101,6 +101,7 @@ struct kvm_regs {
> >  #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
> >  #define KVM_ARM_VCPU_PSCI_0_2		2 /* CPU uses PSCI v0.2 */
> >  #define KVM_ARM_VCPU_PMU_V3		3 /* Support guest PMUv3 */
> > +#define KVM_ARM_VCPU_SVE		4 /* Allow SVE for guest */
> >  
> >  struct kvm_vcpu_init {
> >  	__u32 target;
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> > index 5152362..fb7f6aa 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -58,6 +58,16 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
> >  	return 0;
> >  }
> >  
> > +int kvm_arm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> > +{
> > +	return 0;
> > +}
> > +
> > +void kvm_arm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
> > +{
> > +	kfree(vcpu->arch.sve_state);
> > +}
> > +
> >  static u64 core_reg_offset_from_id(u64 id)
> >  {
> >  	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
> > @@ -600,12 +610,9 @@ int kvm_vcpu_preferred_target(struct kvm_vcpu_init *init)
> >  
> >  	memset(init, 0, sizeof(*init));
> >  
> > -	/*
> > -	 * For now, we don't return any features.
> > -	 * In future, we might use features to return target
> > -	 * specific features available for the preferred
> > -	 * target type.
> > -	 */
> > +	/* KVM_ARM_VCPU_SVE understood by KVM_VCPU_INIT */
> > +	init->features[0] = 1 << KVM_ARM_VCPU_SVE;
> > +
> >  	init->target = (__u32)target;
> >  
> >  	return 0;
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index a74311b..f63a791 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -110,6 +110,20 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  			cpu_reset = &default_regs_reset;
> >  		}
> >  
> > +		if (system_supports_sve() &&
> > +		    test_bit(KVM_ARM_VCPU_SVE, vcpu->arch.features)) {
> > +			vcpu->arch.flags |= KVM_ARM64_GUEST_HAS_SVE;
> > +
> > +			vcpu->arch.sve_max_vl = sve_max_virtualisable_vl;
> > +
> 
> The allocation below needs to be guarded by an if (!vcpu->arch.sve_state),
> otherwise every time the guest does a PSCI-off/PSCI-on cycle of the vcpu
> we'll have a memory leak. Or, we need to move this allocation into the new
> kvm_arm_arch_vcpu_init() function. Why did you opt for kvm_reset_vcpu()?

I think I failed to find another suitable init function that gets called
at the right time.  I may have got confused though.

Good spot on the PSCI interaction.  In light of that, I agree: the SVE
buffer allocation should not be done here.


I'll have a think about how to refactor this in light of the discussion.

Cheers
---Dave

  reply	other threads:[~2018-07-26 13:23 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21 14:57 [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests Dave Martin
2018-06-21 14:57 ` [RFC PATCH 01/16] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2018-07-06  9:07   ` Alex Bennée
2018-06-21 14:57 ` [RFC PATCH 02/16] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2018-07-06  9:08   ` Alex Bennée
2018-06-21 14:57 ` [RFC PATCH 03/16] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2018-07-06  9:20   ` Alex Bennée
2018-06-21 14:57 ` [RFC PATCH 04/16] KVM: arm64: Add missing #include of <linux/bitmap.h> to kvm_host.h Dave Martin
2018-07-06  9:21   ` Alex Bennée
2018-06-21 14:57 ` [RFC PATCH 05/16] KVM: arm: Add arch init/uninit hooks Dave Martin
2018-07-06 10:02   ` Alex Bennée
2018-07-09 15:15     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 06/16] arm64/sve: Determine virtualisation-friendly vector lengths Dave Martin
2018-07-06 13:20   ` Marc Zyngier
2018-06-21 14:57 ` [RFC PATCH 07/16] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2018-07-25 13:58   ` Alex Bennée
2018-07-25 14:39     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 08/16] KVM: arm64: Support dynamically hideable system registers Dave Martin
2018-07-25 14:12   ` Alex Bennée
2018-07-25 14:36     ` Dave Martin
2018-07-25 15:41       ` Alex Bennée
2018-07-26 12:53         ` Dave Martin
2018-08-07 19:20   ` Christoffer Dall
2018-08-08  8:33     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 09/16] KVM: arm64: Allow ID registers to by dynamically read-as-zero Dave Martin
2018-07-25 15:46   ` Alex Bennée
2018-08-06 13:03   ` Christoffer Dall
2018-08-07 11:09     ` Dave Martin
2018-08-07 19:35       ` Christoffer Dall
2018-08-08  9:11         ` Dave Martin
2018-08-08  9:58           ` Christoffer Dall
2018-08-08 14:03           ` Peter Maydell
2018-08-09 10:19             ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 10/16] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2018-07-19 11:08   ` Andrew Jones
2018-07-25 11:41     ` Dave Martin
2018-07-25 13:43       ` Andrew Jones
2018-07-25 14:41         ` Dave Martin
2018-07-19 15:02   ` Andrew Jones
2018-07-25 11:48     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 11/16] KVM: arm64/sve: System register context switch and access support Dave Martin
2018-07-19 11:11   ` Andrew Jones
2018-07-25 11:45     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 12/16] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2018-07-19 13:13   ` Andrew Jones
2018-07-25 11:50     ` Dave Martin
2018-07-25 13:57       ` Andrew Jones
2018-07-25 14:12         ` Dave Martin
2018-08-06 13:19   ` Christoffer Dall
2018-08-07 11:15     ` Dave Martin
2018-08-07 19:43       ` Christoffer Dall
2018-08-08  8:23         ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 13/16] KVM: Allow 2048-bit register access via KVM_{GET, SET}_ONE_REG Dave Martin
2018-07-25 15:58   ` Alex Bennée
2018-07-26 12:58     ` Dave Martin
2018-07-26 13:55       ` Alex Bennée
2018-07-27  9:26         ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 14/16] KVM: arm64/sve: Add SVE support to register access ioctl interface Dave Martin
2018-07-19 13:04   ` Andrew Jones
2018-07-25 14:06     ` Dave Martin
2018-07-25 17:20       ` Andrew Jones
2018-07-26 13:10         ` Dave Martin
2018-08-03 14:57     ` Dave Martin
2018-08-03 15:11       ` Andrew Jones
2018-08-03 15:38         ` Dave Martin
2018-08-06 13:25   ` Christoffer Dall
2018-08-07 11:17     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 15/16] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2018-07-19 14:12   ` Andrew Jones
2018-07-25 14:50     ` Dave Martin
2018-06-21 14:57 ` [RFC PATCH 16/16] KVM: arm64/sve: Report and enable SVE API extensions for userspace Dave Martin
2018-07-19 14:59   ` Andrew Jones
2018-07-25 15:27     ` Dave Martin
2018-07-25 16:52       ` Andrew Jones
2018-07-26 13:18         ` Dave Martin
2018-08-06 13:41           ` Christoffer Dall
2018-08-07 11:23             ` Dave Martin
2018-08-07 20:08               ` Christoffer Dall
2018-08-08  8:30                 ` Dave Martin
2018-07-19 15:24   ` Andrew Jones
2018-07-26 13:23     ` Dave Martin [this message]
2018-07-06  8:22 ` [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests Alex Bennée
2018-07-06  9:05   ` Dave Martin
2018-07-06  9:20     ` Alex Bennée
2018-07-06  9:23       ` Peter Maydell
2018-07-06 10:11         ` Alex Bennée
2018-07-06 10:14           ` Peter Maydell
2018-08-06 13:05 ` Christoffer Dall
2018-08-07 11:18   ` Dave Martin

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=20180726132307.GY4240@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@kernel.org \
    --cc=drjones@redhat.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=tokamoto@jp.fujitsu.com \
    --cc=will.deacon@arm.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