qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 02/27] s390x/cpumodel: fix max STFL(E) bit nu


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH v1 02/27] s390x/cpumodel: fix max STFL(E) bit number
Date: Mon, 25 Sep 2017 10:14:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

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 <address@hidden>

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 <address@hidden>
> ---
>  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;
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]