On Wed, 6 Sep 2017 14:57:48 +0800
QingFeng Hao <[email protected]> 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).
