Re: [PATCH v1 4/4] s390x: Testing the Subchannel I/O read

Cornelia Huck
2019-11-21T16:02:49Z

On Thu, 14 Nov 2019 11:11:18 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:

> On 2019-11-13 14:05, Cornelia Huck wrote:
> > On Wed, 13 Nov 2019 13:23:19 +0100
> > Pierre Morel <pmorel@linux.ibm.com> wrote:
> >
> >> This simple test test the I/O reading by the SUB Channel by:
> >> - initializing the Channel SubSystem with predefined CSSID:
> >> 0xfe000000 CSSID for a Virtual CCW
> > 0 should be fine with recent QEMU versions as well, I guess?
> Right
>
>
> >
> >> 0x00090000 SSID for CCW-PONG
> > subchannel id, or subchannel set id?
>
> hum, only part of, I had SSID (Subchannel Set ID) 4 (a.k.a m bit) + Bit
> 47  =1
>
> But as you said, I can use CSSID 0 and m = 0 which makes:
>
> Subsystem Identification word = 0x00010000

Yeah, I was mainly confused by the name 'SSID'.

> >> - initializing the ORB pointing to a single READ CCW
> > Out of curiosity: Would using a NOP also be an option?
>
> It will work but will not be handled by this device, css.c intercept it
> in sch_handle_start_func_virtual.
>
> AFAIU If we want to have a really good testing environment, for driver
> testing for exemple, then it would be interesting to add a new
> do_subchannel_work callback like do_subchannel_work_emulation along with
> the _virtual and _paththrough variantes.
>
> Having a dedicated callback for emulation, we can answer to any CSS
> instructions and SSCH commands, including NOP and TIC.

I guess that depends on what you want to test; if you actually want to
test device emulation as used by virtio etc., you obviously want to go
through the existing _virtual callback :)

The actual motivation behind my question was:
Is it possible to e.g. throw NOP (or TIC, or something else not
device-specific) at a normal, existing virtio device for test purposes?
You'd end up testing the common emulation code without needing any
extra support in QEMU. No idea how useful that would be.

>
> My goal here was to quickly develop a device answering to some basic
> READ/WRITE command to start memory transfers from inside a guest without
> Linux and without implementing VIRTIO in KVM tests.

Yes, if you want to do some simple memory transfers, virtio is probably
not the first choice. Would e.g. doing a SenseID or so actually be
useful in some way already? After all, it does transfer memory (but
only in one direction).

> >> +static inline int rsch(unsigned long schid)
> > I don't think anyone has tried rsch with QEMU before; sounds like a
> > good idea to test this :)
>
> With an do_subchannel_work_emulation() callback?

You probably need to build a simple channel program that suspends
itself and can be resumed later.