On Thu, 14 Nov 2019 11:11:18 +0100 Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > On 2019-11-13 14:05, Cornelia Huck wrote: > > On Wed, 13 Nov 2019 13:23:19 +0100 > > Pierre Morel <pmorel@xxxxxxxxxxxxx> 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.
