Re: [PATCH v5 06/26] arm64/sve: Check SVE virtualisability

[Dave Martin <Dave.Martin@arm.com>]

On Fri, Mar 01, 2019 at 12:39:52PM +0000, Julien Thierry wrote:
> 
> 
> On 26/02/2019 12:06, Dave Martin wrote:
> > On Wed, Feb 20, 2019 at 11:12:49AM +0000, Julien Thierry wrote:
> >> Hi Dave,
> >>
> >> On 18/02/2019 19:52, Dave Martin wrote:

[...]

> >>> +	/*
> >>> +	 * 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