kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot
@ 2021-01-21  6:57 Thomas Huth
  2021-01-21 12:54 ` Cornelia Huck
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Thomas Huth @ 2021-01-21  6:57 UTC (permalink / raw)
  To: kvm, Janosch Frank; +Cc: David Hildenbrand, cohuck

The "struct CPUEntry entries[0]" in the ReadInfo structure is misleading
since the entries could be add a completely different spot. Replace it
by a proper comment instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 lib/s390x/sclp.h | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/s390x/sclp.h b/lib/s390x/sclp.h
index 9f81c0f..8523133 100644
--- a/lib/s390x/sclp.h
+++ b/lib/s390x/sclp.h
@@ -131,10 +131,15 @@ typedef struct ReadInfo {
 	uint16_t highest_cpu;
 	uint8_t  _reserved5[124 - 122];     /* 122-123 */
 	uint32_t hmfai;
-	uint8_t reserved7[134 - 128];
+	uint8_t reserved7[134 - 128];       /* 128-133 */
 	uint8_t byte_134_diag318 : 1;
 	uint8_t : 7;
-	struct CPUEntry entries[0];
+	/*
+	 * At the end of the ReadInfo, there are also the CPU entries (see
+	 * struct CPUEntry). When the Extended-Length SCCB (ELS) feature is
+	 * enabled, the start of the CPU entries array begins at an offset
+	 * denoted by the offset_cpu field, otherwise it's at offset 128.
+	 */
 } __attribute__((packed)) ReadInfo;
 
 typedef struct ReadCpuInfo {
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot
  2021-01-21  6:57 [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot Thomas Huth
@ 2021-01-21 12:54 ` Cornelia Huck
  2021-01-21 13:03 ` David Hildenbrand
  2021-01-21 13:33 ` Janosch Frank
  2 siblings, 0 replies; 4+ messages in thread
From: Cornelia Huck @ 2021-01-21 12:54 UTC (permalink / raw)
  To: Thomas Huth; +Cc: kvm, Janosch Frank, David Hildenbrand

On Thu, 21 Jan 2021 07:57:03 +0100
Thomas Huth <thuth@redhat.com> wrote:

> The "struct CPUEntry entries[0]" in the ReadInfo structure is misleading
> since the entries could be add a completely different spot. Replace it

s/add/at/

> by a proper comment instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  lib/s390x/sclp.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/s390x/sclp.h b/lib/s390x/sclp.h
> index 9f81c0f..8523133 100644
> --- a/lib/s390x/sclp.h
> +++ b/lib/s390x/sclp.h
> @@ -131,10 +131,15 @@ typedef struct ReadInfo {
>  	uint16_t highest_cpu;
>  	uint8_t  _reserved5[124 - 122];     /* 122-123 */
>  	uint32_t hmfai;
> -	uint8_t reserved7[134 - 128];
> +	uint8_t reserved7[134 - 128];       /* 128-133 */
>  	uint8_t byte_134_diag318 : 1;
>  	uint8_t : 7;
> -	struct CPUEntry entries[0];
> +	/*
> +	 * At the end of the ReadInfo, there are also the CPU entries (see
> +	 * struct CPUEntry). When the Extended-Length SCCB (ELS) feature is
> +	 * enabled, the start of the CPU entries array begins at an offset
> +	 * denoted by the offset_cpu field, otherwise it's at offset 128.
> +	 */

This comment is really helpful, as the difference for ELS had actually
slipped my mind again...

>  } __attribute__((packed)) ReadInfo;
>  
>  typedef struct ReadCpuInfo {

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot
  2021-01-21  6:57 [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot Thomas Huth
  2021-01-21 12:54 ` Cornelia Huck
@ 2021-01-21 13:03 ` David Hildenbrand
  2021-01-21 13:33 ` Janosch Frank
  2 siblings, 0 replies; 4+ messages in thread
From: David Hildenbrand @ 2021-01-21 13:03 UTC (permalink / raw)
  To: Thomas Huth, kvm, Janosch Frank; +Cc: cohuck

On 21.01.21 07:57, Thomas Huth wrote:
> The "struct CPUEntry entries[0]" in the ReadInfo structure is misleading
> since the entries could be add a completely different spot. Replace it
> by a proper comment instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  lib/s390x/sclp.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/s390x/sclp.h b/lib/s390x/sclp.h
> index 9f81c0f..8523133 100644
> --- a/lib/s390x/sclp.h
> +++ b/lib/s390x/sclp.h
> @@ -131,10 +131,15 @@ typedef struct ReadInfo {
>  	uint16_t highest_cpu;
>  	uint8_t  _reserved5[124 - 122];     /* 122-123 */
>  	uint32_t hmfai;
> -	uint8_t reserved7[134 - 128];
> +	uint8_t reserved7[134 - 128];       /* 128-133 */
>  	uint8_t byte_134_diag318 : 1;
>  	uint8_t : 7;
> -	struct CPUEntry entries[0];
> +	/*
> +	 * At the end of the ReadInfo, there are also the CPU entries (see
> +	 * struct CPUEntry). When the Extended-Length SCCB (ELS) feature is
> +	 * enabled, the start of the CPU entries array begins at an offset
> +	 * denoted by the offset_cpu field, otherwise it's at offset 128.
> +	 */
>  } __attribute__((packed)) ReadInfo;
>  
>  typedef struct ReadCpuInfo {
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot
  2021-01-21  6:57 [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot Thomas Huth
  2021-01-21 12:54 ` Cornelia Huck
  2021-01-21 13:03 ` David Hildenbrand
@ 2021-01-21 13:33 ` Janosch Frank
  2 siblings, 0 replies; 4+ messages in thread
From: Janosch Frank @ 2021-01-21 13:33 UTC (permalink / raw)
  To: Thomas Huth, kvm; +Cc: David Hildenbrand, cohuck

On 1/21/21 7:57 AM, Thomas Huth wrote:
> The "struct CPUEntry entries[0]" in the ReadInfo structure is misleading
> since the entries could be add a completely different spot. Replace it
> by a proper comment instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Thanks, picked.
I'll fix up Conny's comment.

> ---
>  lib/s390x/sclp.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/s390x/sclp.h b/lib/s390x/sclp.h
> index 9f81c0f..8523133 100644
> --- a/lib/s390x/sclp.h
> +++ b/lib/s390x/sclp.h
> @@ -131,10 +131,15 @@ typedef struct ReadInfo {
>  	uint16_t highest_cpu;
>  	uint8_t  _reserved5[124 - 122];     /* 122-123 */
>  	uint32_t hmfai;
> -	uint8_t reserved7[134 - 128];
> +	uint8_t reserved7[134 - 128];       /* 128-133 */
>  	uint8_t byte_134_diag318 : 1;
>  	uint8_t : 7;
> -	struct CPUEntry entries[0];
> +	/*
> +	 * At the end of the ReadInfo, there are also the CPU entries (see
> +	 * struct CPUEntry). When the Extended-Length SCCB (ELS) feature is
> +	 * enabled, the start of the CPU entries array begins at an offset
> +	 * denoted by the offset_cpu field, otherwise it's at offset 128.
> +	 */
>  } __attribute__((packed)) ReadInfo;
>  
>  typedef struct ReadCpuInfo {
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-21 14:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-21  6:57 [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot Thomas Huth
2021-01-21 12:54 ` Cornelia Huck
2021-01-21 13:03 ` David Hildenbrand
2021-01-21 13:33 ` Janosch Frank

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).