Thread (56 messages) 56 messages, 6 authors, 2019-04-02

Re: [PATCH v6 19/27] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST

From: Julien Thierry <hidden>
Date: 2019-03-28 14:29:40
Also in: kvmarm


On 28/03/2019 12:27, Dave Martin wrote:
On Wed, Mar 27, 2019 at 03:21:02PM +0000, Julien Thierry wrote:
quoted

On 27/03/2019 10:33, Dave Martin wrote:
quoted
On Wed, Mar 27, 2019 at 09:47:42AM +0000, Julien Thierry wrote:
quoted
Hi Dave,

On 19/03/2019 17:52, Dave Martin wrote:
[...]
quoted
quoted
quoted
quoted
+static unsigned long num_sve_regs(const struct kvm_vcpu *vcpu)
+{
+	/* Only the first slice ever exists, for now */
+	const unsigned int slices = 1;
Nit: Might be worth introducing a macro/inline function for the number
of slices supported. This way, the day we need to change that, we only
need to look for that identifier.
... Reasonable point, but I wanted to avoid inventing anything
prematurely, partly because sve_reg_to_region() will need work in order
to support multiple slices (though it's not rocket science).

I could introduce something like the following:

static unsigned int sve_num_slices(const struct kvm_vcpu *vcpu)
{
	unsigned int slice_size = KVM_REG_SIZE(KVM_REG_ARM64_SVE_ZREG(0, 0));
	unsigned int slices = DIV_ROUND_UP(vcpu->arch.sve_max_vl, slice_size);

	/*
	 * For now, the SVE register ioctl access code won't work
	 * properly with multiple register slices.  KVM should prevent
	 * configuration of a vcpu with a maximum vector length large
	 * enough to trigger this:
	 */
	if (WARN_ON_ONCE(slices > 1))
		return 1;

	return slices;
}

This may be clearer, but felt a bit like overkill...

Thoughts?
Seems a bit overkill yes... I was more thinking of a define and the
person in charge of adding the slice support would just need to look for
references to that define to know (some of) the places that would need
rework/review.

So, unless someone else thinks it's good to introduce it right now you
can ignore that.
OK, how about the following?  This keeps things minimal, but should help
future maintainers know that something may need updating here in the
future. 
Yes, I think this looks good.

Thanks,

-- 
Julien Thierry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help