Re: SCLP Read Events

[Harold Grovesteen]

Thank you for the kind consideration of my situation.  The bios was a
big help in getting the write events to work.  I was unaware that the
read events were also used, so I will need to examine the referenced
function more closely.

As I said, I am sure the problem is mine.  That read events are used in
the bios I am hoping helps.

Harold Grovesteen

On Wed, 2023-05-24 at 11:12 +0200, Thomas Huth wrote:
> On 24/05/2023 10.52, Christian Borntraeger wrote:
> > 
> > 
> > Am 16.05.23 um 15:43 schrieb Harold Grovesteen:
> > > Sorry for the rather long email, but I have hit a major snag in
> > > my work
> > > with QEMU.
> > > 
> > > As part of the SATK (https://github.com/s390guy/SATK) project, I
> > > have
> > > been working on extending bare-metal program support to QEMU by
> > > the
> > > project.
> > > 
> > > Many bare-metal programs at some point need to share information
> > > with
> > > the user.  SCLP write events provide this vehicle and write
> > > events are
> > > working within a bare-metal program.
> > > 
> > > However, SCLP read events, the mechanism one would expect to use
> > > to
> > > allow a query from the user is not.  The implementation makes a
> > > request
> > > for a read event and gets the X'60F0' reason code and response
> > > class
> > > for no available events.
> > > 
> > > That makes perfect sense, because I have not been able to
> > > actually type
> > > any input that could turn into a read event.
> > > 
> > > Is there a configuration option required to enable communication
> > > with
> > > the emulated SCLP console from the QEMU process console input?
> > > 
> > > This is the command by which I invoke QEMU:
> > > 
> > > /home/harold/qemu-7.2.0-rc4/install/bin/qemu-system-s390x -
> > > machine
> > > s390-ccw-virtio -cpu max -m 3M -no-shutdown -nographic -serial
> > > mon:stdio -kernel test9.elf
> > > 
> > > As the command line reflects, I am testing with QEMU 7.2.0 rc4.
> > > 
> > > One of the concerns I have had is that the program terminates
> > > before I
> > > can type the input.  In this regard I have tried various attempts
> > > to
> > > get the program to "continue" by use of timer related
> > > interruptions,
> > > specifically CPU Timer and Clock Comparator external
> > > interruptions.
> > > 
> > > (And, yes, the active PSW is enabled for external interruptions
> > > and the
> > > subclass mask is set as needed in control register zero.)
> > > 
> > > In the case of the CPU Timer it decrements, but never below
> > > zero.  It
> > > stops at zero and does not decrement to a negative value required
> > > for a
> > > CPU Timer external interrupt.
> > > 
> > > In the case of the Clock Comparator, it does not appear to ever
> > > compare
> > > the actual TOD Clock to the Clock Comparator register.  The TOD
> > > Clock
> > > advances past the Clock Comparator, but no external interruption
> > > is
> > > generated.
> > 
> > I think the right way is to use the external interrupt subclass for
> > service calls and not the timer.
> > > 
> > > (Aside, I would be very surprised if Linux itself does not use
> > > one
> > > these types of timer interruptions.  So hoping it just needs
> > > enabling.)
> > 
> > It should just work and it does so for the Linux kernel as far as I
> > know.
> 
> IIRC we're also using it for keyboard input in the s390-ccw bios to
> select 
> different menu entries. Have a look at the sclp_read() function here,
> maybe 
> it could be helpful:
> 
> https://gitlab.com/qemu-project/qemu/-/blob/master/pc-bios/s390-ccw/sclp.c#L121
> 
>   Thomas
> 
> 
>