On Wed, 6 Sep 2017 14:57:48 +0800 QingFeng Hao <ha...@linux.vnet.ibm.com> wrote:
> 在 2017/9/5 23:16, Cornelia Huck 写道: > > Recent changes in s390x made pci support dependant on the zpci cpu > > feature, which is not provided on all models (and not on by default). > > This means we cannot instatiate pci devices on a standard qemu > > invocation for s390x. Moreover, the zpci instructions are not even > > wired up for tcg yet, so actually doing anything with those pci devices > > is bound to fail on tcg. > > > > Let's follow the existing example in 068 and switch to the (default) > > virtio-ccw transport on s390x. The changes for 051 and 067 are split > > out as they require adding an output file for s390x (the actual command > > lines are part of the output). > We also found this error and YiMin suggested to change the code in ccw_init > as below: > > if (pci_available) { > DeviceState *dev = qdev_create(NULL, TYPE_S390_PCI_HOST_BRIDGE); > ... > } > We tested it and it can make the 5 cases passed. OK, looked at this. This won't work: pci_available means "this qemu has pci support built in". _Working_ zpci, however, depends on the presence of the zpci feature bit: You'll have a host bridge and can define devices that have absolutely no chance of working, since all pci instruction will return errors. You will be in a similar situation under kvm as under tcg: you can specify virtio-pci devices on the command line, but they can't work. This probably makes the 5 cases pass as they only rely on the ability to create the device, not to do anything with them. So, I still think the right thing to do is to switch to ccw in the tests (and to wire up pci in tcg, but that's an orthogonal issue).