Makes sense. I asked myself if there is code outside that does not zero out
2048-16k so
I looked into the kernel source and it looks like we always did the right thing
(and zeroed out the response buffer), so this should not uncover any bugs.
Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com>
On 09/18/2017 05:59 PM, David Hildenbrand wrote:
> Not that it would matter in the near future, but it is actually 2048
> bytes, therefore 16384 possible bits.
>
> Signed-off-by: David Hildenbrand <da...@redhat.com>
> ---
> target/s390x/cpu_features.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 1d3a036393..31a4676f05 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -381,7 +381,7 @@ void s390_add_from_feat_block(S390FeatBitmap features,
> S390FeatType type,
>
> switch (type) {
> case S390_FEAT_TYPE_STFL:
> - nr_bits = 2048;
> + nr_bits = 16384;
> break;
> case S390_FEAT_TYPE_PLO:
> nr_bits = 256;
>
