qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 2/7] s390x/css: IO instr handler ending contr


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH v3 2/7] s390x/css: IO instr handler ending control
Date: Tue, 17 Oct 2017 16:58:17 +0200

On Tue, 17 Oct 2017 16:04:48 +0200
Halil Pasic <address@hidden> wrote:

> CSS code needs to tell the IO instruction handlers located in how should
> the emulated instruction be ended. Currently this is done by returning
> generic (POSIX) error codes, and mapping them to outcomes like condition
> codes. This makes bugs easy to create and hard to recognise.
> 
> As a preparation for moving a way form (mis)using generic error codes for

s/form/from/

> flow control let us introduce a type which tells the instruction
> handler function how to end the instruction, in a more straight-forward
> and less ambiguous way.
> 
> Signed-off-by: Halil Pasic <address@hidden>
> ---
>  include/hw/s390x/css.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
> index 69b374730e..7e0dbd162f 100644
> --- a/include/hw/s390x/css.h
> +++ b/include/hw/s390x/css.h
> @@ -99,6 +99,22 @@ typedef struct CcwDataStream {
>      hwaddr cda;
>  } CcwDataStream;
>  
> +/*
> + * IO instructions conclude according this. Currently we have only

s/this/to this/

> + * cc codes. Valid values are 0,1,2,3 and the generic semantic for

blanks between numbers?

> + * IO instructions is described briefly. For more details consult the PoP.
> + */
> +typedef enum IOInstEnding {
> +    /* produced expected result */
> +    IOINST_CC_EXPECTED = 0,
> +    /* status conditions were present or produced alternate result */
> +    IOINST_CC_STATUS_PRESENT = 1,
> +    /* inst. ineffective because busy with previously initiated function */
> +    IOINST_CC_BUSY = 2,
> +    /* inst. ineffective because not operational */
> +    IOINST_CC_NOT_OPERATIONAL = 3
> +} IOInstEnding;

This looks a bit odd for some I/O instructions (STCRW, TPI, TSCH), but
is fine for the others. But as the PoP also defines the meanings as
above, it should be fine (and not confusing).

> +
>  typedef struct SubchDev SubchDev;
>  struct SubchDev {
>      /* channel-subsystem related things: */




reply via email to

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