* Cornelia Huck <coh...@redhat.com> [2017-09-07 10:08:17 +0200]: [...]
> > I'm thinking of a method these days: > > Could passing through an fully emulated ccw device (e.g. 3270), or a > > virtio ccw device, in the level 1 kvm guest to a level 2 guest be a test > > method for this? > > > > All of the CCWs will be translated to IDAL CCWs by vfio-ccw in the level > > 1 guest (which is the level 2 kvm host) and issued to the level 1 kvm > > host. So, those IDALs will eventually be handled by the emulated device, > > or the virtio ccw device, on the level 1 kvm host... > > > > Some days ago, one of my colleague tried the emulated 3270 passing > > through. She stucked with the problem that the level 1 kvm host handling > > a senseid IDAL ccw as a Direct ccw. > > > > Maybe I could try to pass through a virtio ccw device. I don't think of > > any obvious problem that would lead to fail. Any comment? > > > > That actually looks like a good thing to try! Cool idea. > Tried to test with the following method: 1. Start g1 (first level guest on kvm a host) with a virtio blk device defined: -drive file=/dev/disk/by-path/ccw-0.0.3f3e,if=none,id=drive-virtio-disk1,format=raw \ -device virtio-blk-ccw,devno=fe.0.2222,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1 \ 2. Login g1, and bind the subchannel of ccw device 0.0.2222 with vfio-ccw drvier. 3. Create a mdev on the above subchannel. 4. Passthrough the mdev to g2, and try to start g2. The 4th step failed with the following message and hang: qemu-system-s390x: vfio-ccw: wirte I/O region: errno=4 (BTW, 4 is EINTR.) I roughly guess this might be caused by: On the kvm host, virtio callback injects the I/O interrupt in a synchronzing manner. And this causes g1's I/O interrupt handler getting the interrupt and then signaling the Qemu instance on g1 with the I/O result, even before return of the pwrite(). But, using gdb on the kvm host, I do see several ssch successfully executed. I will dig the root reason, and see if there is some way to fix the issue. -- Dong Jia Shi
