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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
