public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Nico Boehr <nrb@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org
Cc: imbrenda@linux.ibm.com, thuth@redhat.com
Subject: Re: [kvm-unit-tests PATCH v1 1/4] lib: s390x: add support for SCLP console read
Date: Wed, 13 Apr 2022 17:00:54 +0200	[thread overview]
Message-ID: <0f21ad244492d1b26d2091fa7189b9967be31f22.camel@linux.ibm.com> (raw)
In-Reply-To: <19e481fb-9804-b42c-7554-8388889dbf73@linux.ibm.com>

On Tue, 2022-04-12 at 17:32 +0200, Janosch Frank wrote:
> On 4/11/22 12:07, Nico Boehr wrote:
> > Add a basic implementation for reading from the SCLP ACII console.
> > The goal of
> > this is to support migration tests on s390x. To know when the
> > migration has been
> > finished, we need to listen for a newline on our console.
> > 
> > Hence, this implementation is focused on the SCLP ASCII console of
> > QEMU and
> > currently won't work under e.g. LPAR.
> 
> How much pain would it be to add the line mode read?

I am not terribly familiar with the line mode, but I can say it would
make the implementation of the ASCII console more complex. Right now we
can just assume there will just be events from the ASCII console when
we read event data.

Not impossible to do, but I thought we don't need it so I kept things
simple. Is there some benefit we would have from the line mode console?

[...]
> >   
> > +static void sclp_console_enable_read(void)
> > +{
> > +       sclp_write_event_mask(SCLP_EVENT_MASK_MSG_ASCII,
> > SCLP_EVENT_MASK_MSG_ASCII | SCLP_EVENT_MASK_MSG);
> > +}
> > +
> > +static void sclp_console_disable_read(void)
> > +{
> > +       sclp_write_event_mask(0, SCLP_EVENT_MASK_MSG_ASCII |
> > SCLP_EVENT_MASK_MSG);
> > +}
> > +
> >   void sclp_console_setup(void)
> >   {
> > -       sclp_set_write_mask();
> > +       /* We send ASCII and line mode. */
> > +       sclp_write_event_mask(0, SCLP_EVENT_MASK_MSG_ASCII |
> > SCLP_EVENT_MASK_MSG);
> >   }
> >   
> >   void sclp_print(const char *str)
> > @@ -227,3 +240,59 @@ void sclp_print(const char *str)
> >         sclp_print_ascii(str);
> >         sclp_print_lm(str);
> >   }
> > +
> > +#define SCLP_EVENT_ASCII_DATA_STREAM_FOLLOWS 0
> 
> -> sclp.h

Yes, thanks.

> 
> > +
> > +static int console_refill_read_buffer(void)
> > +{
> > +       const int MAX_EVENT_BUFFER_LEN = SCCB_SIZE -
> > offsetof(ReadEventDataAsciiConsole, ebh);
> > +       ReadEventDataAsciiConsole *sccb = (void *)_sccb;
> > +       const int EVENT_BUFFER_ASCII_RECV_HEADER_LEN = sizeof(sccb-
> > >ebh) + sizeof(sccb->type);
> > +       int ret = -1;
> 
> Reverse Christmas tree

Hm, I think it's not possible for EVENT_BUFFER_ASCII_RECV_HEADER_LEN
because it needs sccb first. I would want to leave as-is except if you
have a better idea on how to do this?

> The const int variables are all caps because they are essentially
> constants?

Yes, that was my reasoning. But it is uncommon in kvm-unit-test to have
it uppercase, all const ints in the codebase are lowercase, so I will
lowercase it.

> > +
> > +       sclp_console_enable_read();
> > +
> > +       sclp_mark_busy();
> > +       memset(sccb, 0, 4096);
> 
> sizeof(*sccb)

If you are OK with it, I would prefer to use SCCB_SIZE, s.t. the entire
buffer is cleared.

  reply	other threads:[~2022-04-13 15:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 10:07 [kvm-unit-tests PATCH v1 0/4] s390x: add migration test suport Nico Boehr
2022-04-11 10:07 ` [kvm-unit-tests PATCH v1 1/4] lib: s390x: add support for SCLP console read Nico Boehr
2022-04-12  8:02   ` Thomas Huth
2022-04-13 14:41     ` Nico Boehr
2022-04-12 15:32   ` Janosch Frank
2022-04-13 15:00     ` Nico Boehr [this message]
2022-04-11 10:07 ` [kvm-unit-tests PATCH v1 2/4] s390x: add support for migration tests Nico Boehr
2022-04-11 12:58   ` Claudio Imbrenda
2022-04-12  8:05   ` Thomas Huth
2022-04-11 10:07 ` [kvm-unit-tests PATCH v1 3/4] s390x: don't run migration tests under PV Nico Boehr
2022-04-11 12:58   ` Claudio Imbrenda
2022-04-12  8:06   ` Thomas Huth
2022-04-11 10:07 ` [kvm-unit-tests PATCH v1 4/4] s390x: add selftest for migration Nico Boehr
2022-04-11 12:49   ` Claudio Imbrenda
2022-04-12 11:49     ` Nico Boehr
2022-04-13  8:42       ` Claudio Imbrenda
2022-04-11 15:30   ` Thomas Huth
2022-04-12  7:41     ` Nico Boehr
2022-04-12  7:49       ` Thomas Huth
2022-04-13 14:32         ` Nico Boehr

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=0f21ad244492d1b26d2091fa7189b9967be31f22.camel@linux.ibm.com \
    --to=nrb@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox