All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Farman <farman@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH v4 1/4] s390x/css: Introduce an ESW struct
Date: Fri, 18 Jun 2021 08:55:18 -0400	[thread overview]
Message-ID: <adca6d5e3c3037da7923489fa28fcd34be099e75.camel@linux.ibm.com> (raw)
In-Reply-To: <874kdvpchd.fsf@redhat.com>

On Fri, 2021-06-18 at 14:46 +0200, Cornelia Huck wrote:
> On Fri, Jun 18 2021, Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Fri, Jun 18 2021, Eric Farman <farman@linux.ibm.com> wrote:
> > 
> > > The Interrupt Response Block is comprised of several other
> > > structures concatenated together, but only the 12-byte
> > > Subchannel-Status Word (SCSW) is defined as a proper struct.
> > > Everything else is a simple array of 32-bit words.
> > > 
> > > Let's define a proper struct for the 20-byte Extended-Status
> > > Word (ESW) so that we can make good decisions about the sense
> > > data that would go into the ECW area for virtual vs
> > > passthrough devices.
> > > 
> > > Signed-off-by: Eric Farman <farman@linux.ibm.com>
> > > ---
> > >  hw/s390x/css.c            | 19 +++++++++++++------
> > >  include/hw/s390x/ioinst.h | 12 +++++++++++-
> > >  2 files changed, 24 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/include/hw/s390x/ioinst.h
> > > b/include/hw/s390x/ioinst.h
> > > index c6737a30d4..e7ab401781 100644
> > > --- a/include/hw/s390x/ioinst.h
> > > +++ b/include/hw/s390x/ioinst.h
> > > @@ -123,10 +123,20 @@ typedef struct SCHIB {
> > >      uint8_t mda[4];
> > >  } QEMU_PACKED SCHIB;
> > >  
> > > +/* format-0 extended-status word */
> > > +typedef struct ESW {
> > > +   uint32_t word0;
> > > +   uint32_t erw;
> > > +   uint64_t f_addr;     /* Zeros for other ESW formats */
> > > +   uint32_t s_addr;     /* Zeros for other ESW formats */
> > > +} QEMU_PACKED ESW;
> > 
> > Eww, this fails with mingw:
> > https://gitlab.com/cohuck/qemu/-/jobs/1358335494
> > 
> > i686-w64-mingw32-gcc -Ilibcommon.fa.p -I../slirp -I../slirp/src
> > -I../dtc/libfdt -I../capstone/include/capstone -I. -Iqapi -Itrace
> > -Iui -Iui/shader -I/usr/i686-w64-mingw32/sys-root/mingw/include
> > -I/usr/i686-w64-mingw32/sys-root/mingw/include/glib-2.0
> > -I/usr/i686-w64-mingw32/sys-root/mingw/lib/glib-2.0/include
> > -I/usr/i686-w64-mingw32/sys-root/mingw/include/gtk-3.0 -I/usr/i686-
> > w64-mingw32/sys-root/mingw/include/cairo -I/usr/i686-w64-
> > mingw32/sys-root/mingw/include/pango-1.0 -I/usr/i686-w64-
> > mingw32/sys-root/mingw/include/fribidi -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/harfbuzz -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/atk-1.0 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/pixman-1 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/freetype2 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/libpng16 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/gdk-pixbuf-2.0 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/lib/libffi-3.1/include -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/p11-kit-1 -I/usr/i686-w64-mingw32/sys-
> > root/mingw/include/SDL2 -fdiagnostics-color=auto -pipe -Wall
> > -Winvalid-pch -Werror -std=gnu99 -O2 -g -iquote . -iquote
> > /builds/cohuck/qemu -iquote /builds/cohuck/qemu/include -iquote
> > /builds/cohuck/qemu/disas/libvixl -iquote
> > /builds/cohuck/qemu/tcg/i386 -mms-bitfields -U_FORTIFY_SOURCE
> > -D_FORTIFY_SOURCE=2 -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> > -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef
> > -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-
> > common -fwrapv -Wold-style-declaration -Wold-style-definition
> > -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-
> > qualifiers -Wempty-body -Wnested-externs -Wendif-labels
> > -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-
> > include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-
> > protector-strong -Dmain=SDL_main -Wno-undef -mms-bitfields -mms-
> > bitfields -mms-bitfields -MD -MQ libcommon.fa.p/hw_s390x_virtio-
> > ccw-gpu.c.obj -MF libcommon.fa.p/hw_s390x_virtio-ccw-gpu.c.obj.d -o
> > libcommon.fa.p/hw_s390x_virtio-ccw-gpu.c.obj -c ../hw/s390x/virtio-
> > ccw-gpu.c
> > In file included from /usr/i686-w64-mingw32/sys-
> > root/mingw/include/winsock2.h:54,
> >                  from /builds/cohuck/qemu/include/sysemu/os-
> > win32.h:29,
> >                  from /builds/cohuck/qemu/include/qemu/osdep.h:135,
> >                  from ../hw/s390x/virtio-ccw-gpu.c:11:
> > /builds/cohuck/qemu/include/hw/s390x/ioinst.h:131:13: error:
> > expected ':', ',', ';', '}' or '__attribute__' before '.' token
> >   131 |    uint32_t s_addr;     /* Zeros for other ESW formats */
> >       |             ^~~~~~
> 
> It seems to be the name that is tripping it; if I rename it to
> sec_addr
> and the preceding field to fail_addr, the build passes.

I was just wondering if it might have been the underscore directly, not
that it was a single letter before the underscore. Weird.

> 
> Anyone know why that is? And if renaming is unavoidable, are
> fail_addr
> and sec_addr ok, or can we find better names?

Since they're zero for Format-!0 ESWs, and regardless we don't fill
them in anyway, could we just make them wordN and change the comment to
give the descriptive name?

 /* format-0 extended-status word */
 typedef struct ESW {
-   uint32_t
word0;
+   uint32_t word0;      /* subchannel logout for format 0 */
    
uint32_t erw;
-   uint64_t f_addr;     /* Zeros for other ESW formats */
-   uint32_t s_addr;     /* Zeros for other ESW formats */
+   uint64_t
word2;      /* failing-storage address for format 0 */
+   uint32_t
word4;      /* scondary-CCW address for format 0 */
 } QEMU_PACKED ESW;

> 
> > In file included from /builds/cohuck/qemu/include/qemu/osdep.h:37,
> >                  from ../hw/s390x/virtio-ccw-gpu.c:11:
> > /builds/cohuck/qemu/include/qemu/compiler.h:80:36: error: static
> > assertion failed: "size of IRB is wrong"
> >    80 | #define QEMU_BUILD_BUG_MSG(x, msg) _Static_assert(!(x),
> > msg)
> >       |                                    ^~~~~~~~~~~~~~
> > /builds/cohuck/qemu/include/hw/s390x/ioinst.h:143:1: note: in
> > expansion of macro 'QEMU_BUILD_BUG_MSG'
> >   143 | QEMU_BUILD_BUG_MSG(sizeof(IRB) != 96, "size of IRB is
> > wrong");
> >       | ^~~~~~~~~~~~~~~~~~
> > 
> 
> These were just follow-on errors.
> 
> > > +
> > > +#define ESW_ERW_SENSE 0x01000000
> > > +
> > >  /* interruption response block */
> > >  typedef struct IRB {
> > >      SCSW scsw;
> > > -    uint32_t esw[5];
> > > +    ESW esw;
> > >      uint32_t ecw[8];
> > >      uint32_t emw[8];
> > >  } IRB;



  reply	other threads:[~2021-06-18 12:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 23:25 [PATCH v4 0/4] s390x: Fix IRB sense data Eric Farman
2021-06-17 23:25 ` [PATCH v4 1/4] s390x/css: Introduce an ESW struct Eric Farman
2021-06-18  9:38   ` Cornelia Huck
2021-06-18 12:57     ` Eric Farman
2021-06-18 11:04   ` Cornelia Huck
2021-06-18 12:46     ` Cornelia Huck
2021-06-18 12:55       ` Eric Farman [this message]
2021-06-18 13:11         ` Cornelia Huck
2021-07-06  9:39   ` Philippe Mathieu-Daudé
2021-06-17 23:25 ` [PATCH v4 2/4] s390x/css: Split out the IRB sense data Eric Farman
2021-06-17 23:25 ` [PATCH v4 3/4] s390x/css: Refactor IRB construction Eric Farman
2021-06-17 23:25 ` [PATCH v4 4/4] s390x/css: Add passthrough IRB Eric Farman
2021-06-18  9:42 ` [PATCH v4 0/4] s390x: Fix IRB sense data Cornelia Huck
2021-06-18 15:27 ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adca6d5e3c3037da7923489fa28fcd34be099e75.camel@linux.ibm.com \
    --to=farman@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.