Re: [Qemu-devel] [qemu-s390x] [PATCH v7 05/12] s390-ccw: move auxiliary IPL data to separate location

[Thomas Huth]

On 19.02.2018 13:15, Viktor Mihajlovski wrote:
> On 19.02.2018 09:50, Viktor Mihajlovski wrote:
>> On 17.02.2018 09:11, Thomas Huth wrote:
>> [...]
>>>
>>> I still think that the information should *not* be stored within the
>>> IplParameterBlock to avoid that we pass it via DIAG 0x308, too.
>>> If we do it like this, I'm pretty sure that we will look at this code in
>>> a couple of years and wonder whether we can change it again or whether
>>> this is an established interface between the host and the guest. So
>>> please, let's avoid establishing such "hidden" interfaces just out of
>>> current convenience. There must be a better location for this.
>>> Christian, do you have an idea?
>>>
>>>  Thomas
>>>
>> In principle I do agree, although I think we can manage the host/guest
>> boundary. If we believe we can't, we have a much bigger problem (looking
>> at the position of the iplb smack in the middle of the s390-ipl state).
>>
>> The main reason why I didn't bother to introduce a new private field in
>> s390-ipl was that I expect more changes to the IPL area in the future
>> (earlier than in a couple of years) and am not really sure whether this
>> QEMU <-> BIOS interface will remain the same and how much effort to
>> spend on it.
>>
>> The major point of this change is to move non-standard data out of the
>> guest-visible IPLB to avoid compatibility problems in the future, while
>> still catering for features like network boot and boot menus. I have no
>> bias against other solutions achieving this objective. If you and
>> Christian think we need a new field, it's all right with me.
>>
> With below squashed in (and a subsequent fixup for the next patch), we can
> logically separate the QEMU IPL parameter from the IPLB. Better?

Yes, sounds much better to me! Collin, could you please squash that in?

 Thanks,
  Thomas


> ---
> diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> index 31565ce..c5923b5 100644
> --- a/hw/s390x/ipl.c
> +++ b/hw/s390x/ipl.c
> @@ -410,7 +410,7 @@ static void s390_ipl_prepare_qipl(S390CPU *cpu)
>  error_report("Cannot set QEMU IPL parameters");
>  return;
>  }
> -memcpy(addr + QIPL_ADDRESS, >iplb.qipl, sizeof(QemuIplParameters));
> +memcpy(addr + QIPL_ADDRESS, >qipl, sizeof(QemuIplParameters));
>  cpu_physical_memory_unmap(addr, len, 1, len);
>  }
>  
> @@ -433,7 +433,7 @@ void s390_ipl_prepare_cpu(S390CPU *cpu)
>  error_report_err(err);
>  vm_stop(RUN_STATE_INTERNAL_ERROR);
>  }
> -ipl->iplb.qipl.netboot_start_addr = cpu_to_be64(ipl->start_addr);
> +ipl->qipl.netboot_start_addr = cpu_to_be64(ipl->start_addr);
>  }
>  s390_ipl_prepare_qipl(cpu);
>  
> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
> index 74469b1..775d363 100644
> --- a/hw/s390x/ipl.h
> +++ b/hw/s390x/ipl.h
> @@ -88,7 +88,6 @@ union IplParameterBlock {
>  IplBlockFcp fcp;
>  IplBlockQemuScsi scsi;
>  };
> -QemuIplParameters qipl;
>  } QEMU_PACKED;
>  struct {
>  uint8_t  reserved1[110];
> @@ -120,6 +119,7 @@ struct S390IPLState {
>  bool iplb_valid;
>  bool reipl_requested;
>  bool netboot;
> +QemuIplParameters qipl;
>  
>  /*< public >*/
>  char *kernel;
> 
> 

Re: [Qemu-devel] [qemu-s390x] [PATCH v7 05/12] s390-ccw: move auxiliary IPL data to separate location

[Viktor Mihajlovski]

On 19.02.2018 09:50, Viktor Mihajlovski wrote:
> On 17.02.2018 09:11, Thomas Huth wrote:
> [...]
>>
>> I still think that the information should *not* be stored within the
>> IplParameterBlock to avoid that we pass it via DIAG 0x308, too.
>> If we do it like this, I'm pretty sure that we will look at this code in
>> a couple of years and wonder whether we can change it again or whether
>> this is an established interface between the host and the guest. So
>> please, let's avoid establishing such "hidden" interfaces just out of
>> current convenience. There must be a better location for this.
>> Christian, do you have an idea?
>>
>>  Thomas
>>
> In principle I do agree, although I think we can manage the host/guest
> boundary. If we believe we can't, we have a much bigger problem (looking
> at the position of the iplb smack in the middle of the s390-ipl state).
> 
> The main reason why I didn't bother to introduce a new private field in
> s390-ipl was that I expect more changes to the IPL area in the future
> (earlier than in a couple of years) and am not really sure whether this
> QEMU <-> BIOS interface will remain the same and how much effort to
> spend on it.
> 
> The major point of this change is to move non-standard data out of the
> guest-visible IPLB to avoid compatibility problems in the future, while
> still catering for features like network boot and boot menus. I have no
> bias against other solutions achieving this objective. If you and
> Christian think we need a new field, it's all right with me.
> 
With below squashed in (and a subsequent fixup for the next patch), we can
logically separate the QEMU IPL parameter from the IPLB. Better?

---
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 31565ce..c5923b5 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -410,7 +410,7 @@ static void s390_ipl_prepare_qipl(S390CPU *cpu)
 error_report("Cannot set QEMU IPL parameters");
 return;
 }
-memcpy(addr + QIPL_ADDRESS, >iplb.qipl, sizeof(QemuIplParameters));
+memcpy(addr + QIPL_ADDRESS, >qipl, sizeof(QemuIplParameters));
 cpu_physical_memory_unmap(addr, len, 1, len);
 }
 
@@ -433,7 +433,7 @@ void s390_ipl_prepare_cpu(S390CPU *cpu)
 error_report_err(err);
 vm_stop(RUN_STATE_INTERNAL_ERROR);
 }
-ipl->iplb.qipl.netboot_start_addr = cpu_to_be64(ipl->start_addr);
+ipl->qipl.netboot_start_addr = cpu_to_be64(ipl->start_addr);
 }
 s390_ipl_prepare_qipl(cpu);
 
diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
index 74469b1..775d363 100644
--- a/hw/s390x/ipl.h
+++ b/hw/s390x/ipl.h
@@ -88,7 +88,6 @@ union IplParameterBlock {
 IplBlockFcp fcp;
 IplBlockQemuScsi scsi;
 };
-QemuIplParameters qipl;
 } QEMU_PACKED;
 struct {
 uint8_t  reserved1[110];
@@ -120,6 +119,7 @@ struct S390IPLState {
 bool iplb_valid;
 bool reipl_requested;
 bool netboot;
+QemuIplParameters qipl;
 
 /*< public >*/
 char *kernel;


-- 
Regards,
 Viktor Mihajlovski

Re: [Qemu-devel] [qemu-s390x] [PATCH v7 05/12] s390-ccw: move auxiliary IPL data to separate location

[Viktor Mihajlovski]

On 17.02.2018 09:11, Thomas Huth wrote:
[...]
> 
> I still think that the information should *not* be stored within the
> IplParameterBlock to avoid that we pass it via DIAG 0x308, too.
> If we do it like this, I'm pretty sure that we will look at this code in
> a couple of years and wonder whether we can change it again or whether
> this is an established interface between the host and the guest. So
> please, let's avoid establishing such "hidden" interfaces just out of
> current convenience. There must be a better location for this.
> Christian, do you have an idea?
> 
>  Thomas
> 
In principle I do agree, although I think we can manage the host/guest
boundary. If we believe we can't, we have a much bigger problem (looking
at the position of the iplb smack in the middle of the s390-ipl state).

The main reason why I didn't bother to introduce a new private field in
s390-ipl was that I expect more changes to the IPL area in the future
(earlier than in a couple of years) and am not really sure whether this
QEMU <-> BIOS interface will remain the same and how much effort to
spend on it.

The major point of this change is to move non-standard data out of the
guest-visible IPLB to avoid compatibility problems in the future, while
still catering for features like network boot and boot menus. I have no
bias against other solutions achieving this objective. If you and
Christian think we need a new field, it's all right with me.

-- 
Regards,
 Viktor Mihajlovski

Re: [Qemu-devel] [qemu-s390x] [PATCH v7 05/12] s390-ccw: move auxiliary IPL data to separate location

[Thomas Huth]

On 16.02.2018 23:07, Collin L. Walling wrote:
> The s390-ccw firmware needs some information in support of the
> boot process which is not available on the native machine.
> Examples are the netboot firmware load address and now the
> boot menu parameters.
> 
> While storing that data in unused fields of the IPL parameter block
> works, that approach could create problems if the parameter block
> definition should change in the future. Because then a guest could
> overwrite these fields using the set IPLB diagnose.
> 
> In fact the data in question is of more global nature and not really
> tied to an IPL device, so separating it is rather logical.
> 
> This commit introduces a new structure to hold firmware relevant
> IPL parameters set by QEMU. The data is stored at location 204 (dec)
> and can contain up to 7 32-bit words. This area is available to
> programming in the z/Architecture Principles of Operation and
> can thus safely be used by the firmware until the IPL has completed.
> 
> Signed-off-by: Viktor Mihajlovski 
> Signed-off-by: Collin L. Walling 
> ---
[...]
> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
> index 8a705e0..74469b1 100644
> --- a/hw/s390x/ipl.h
> +++ b/hw/s390x/ipl.h
> @@ -16,8 +16,7 @@
>  #include "cpu.h"
>  
>  struct IplBlockCcw {
> -uint64_t netboot_start_addr;
> -uint8_t  reserved0[77];
> +uint8_t  reserved0[85];
>  uint8_t  ssid;
>  uint16_t devno;
>  uint8_t  vm_flags;
> @@ -59,6 +58,21 @@ typedef struct IplBlockQemuScsi IplBlockQemuScsi;
>  
>  #define DIAG308_FLAGS_LP_VALID 0x80
>  
> +#define QIPL_ADDRESS  0xcc
> +
> +/*
> + * The QEMU IPL Parameters will be stored 32-bit word aligned.
> + * Placement of data fields in this area must account for
> + * their alignment needs.
> + * The entire structure must not be larger than 28 bytes.
> + */
> +struct QemuIplParameters {
> +uint8_t  reserved1[4];
> +uint64_t netboot_start_addr;
> +uint8_t  reserved2[16];
> +} QEMU_PACKED;
> +typedef struct QemuIplParameters QemuIplParameters;
> +
>  union IplParameterBlock {
>  struct {
>  uint32_t len;
> @@ -74,6 +88,7 @@ union IplParameterBlock {
>  IplBlockFcp fcp;
>  IplBlockQemuScsi scsi;
>  };
> +QemuIplParameters qipl;
>  } QEMU_PACKED;
>  struct {
>  uint8_t  reserved1[110];

I still think that the information should *not* be stored within the
IplParameterBlock to avoid that we pass it via DIAG 0x308, too.
If we do it like this, I'm pretty sure that we will look at this code in
a couple of years and wonder whether we can change it again or whether
this is an established interface between the host and the guest. So
please, let's avoid establishing such "hidden" interfaces just out of
current convenience. There must be a better location for this.
Christian, do you have an idea?

 Thomas