On Thu, 21 Sep 2017 16:45:47 +0800 Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote:
> * 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. Hm... would that be the ccws used for setting up a virtio device, and the problems start once adapter interrupts become active? Does it work if you modify the nested guest to use the old per-subchannel indicators mechanism? (I'm also wondering how diag is handled?)
