Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

[Cornelia Huck]

On Thu, 21 Sep 2017 16:45:47 +0800
Dong Jia Shi <address@hidden> wrote:

> * Cornelia Huck <address@hidden> [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?)