[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device |
Date: |
Thu, 21 Sep 2017 10:54:02 +0200 |
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?)
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, (continued)
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/07
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Cornelia Huck, 2017/09/07
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Halil Pasic, 2017/09/07
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Cornelia Huck, 2017/09/07
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/07
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Halil Pasic, 2017/09/08
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/19
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/21
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device,
Cornelia Huck <=
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/26
- Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device, Dong Jia Shi, 2017/09/27
[Qemu-devel] [PATCH 4/5] s390x/css: support ccw IDA, Halil Pasic, 2017/09/05
Re: [Qemu-devel] [PATCH 0/5] add CCW indirect data access support, Halil Pasic, 2017/09/08