On Fri, Mar 01, 2019 at 12:39:52PM +0000, Julien Thierry wrote:

On 26/02/2019 12:06, Dave Martin wrote:

quoted

On Wed, Feb 20, 2019 at 11:12:49AM +0000, Julien Thierry wrote:

quoted

Hi Dave,

On 18/02/2019 19:52, Dave Martin wrote:

[...]

quoted

quoted

quoted

+	/*
+	 * Mismatches above sve_max_virtualisable_vl are fine, since
+	 * no guest is allowed to configure ZCR_EL2.LEN to exceed this:
+	 */
+	if (sve_vl_from_vq(bit_to_vq(b)) <= sve_max_virtualisable_vl) {
+		pr_warn("SVE: cpu%d: Unsupported vector length(s) present\n",

Nit: might be good to specify that the vector length is unsupported for
virtualisation.

Also, since KVM is the one deciding what to do with the information,
should we have a warning here? But I can understand that knowing which
CPUs are introducing unsupported vector length, maybe using pr_devel()
instead of pr_warn()

These warnings are really for consumption by SoC vendors, not users:
my aim is to flag up systems that we consider broken (or at least,
unsuitable for running KVM).

So I prefer to make this noisy and limit the amount of "useful"
information people might be tempted to programmatically scrape from
dmesg.

cpufeatures uses pr_warn("SANITY CHECK: [...]") here.  Maybe I should
stick "SANITY CHECK" in here too?  I will also try to make the commit
message more explicit and/or add comments to make the intent of the code
clearer.

It may also make sense to make this noise even if KVM isn't enabled
(which is a rare case anyhow).

Thoughts?

As I explained later in the patch series, I missed the fact that this
function was for late secondary CPUs. I think things are fine like this
(just add the bit about the vector lenght not being supported for
virtualisation).

I've now reworked all this a bit: I probe for the largest vector length
than be offered to guests, and if this is less than the host's maximum
vector length then I print a one-off warning saying what limit KVM is
clamping guests' vector length to.

Elsewhere, I now just use the probed value as the maximum vector length,
rather than duplicating the bounds checking logic.

This approach seems simpler, and is hoepfully a bit more self-
explanatory -- so please take a look when I repost :)

Cheers
---Dave

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