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

[Cornelia Huck <cohuck@redhat.com>]

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.