qemu-devel
[Top][All Lists]
Advanced

[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: Dong Jia Shi
Subject: Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device
Date: Thu, 21 Sep 2017 16:45:47 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

* 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.

-- 
Dong Jia Shi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]