tests/qemu-iotests/040 | 6 +- tests/qemu-iotests/051 | 9 +- tests/qemu-iotests/051.s390-ccw-virtio.out | 434 +++++++++++++++++++++++++++ tests/qemu-iotests/067 | 11 +- tests/qemu-iotests/067.s390-ccw-virtio.out | 458 +++++++++++++++++++++++++++++ tests/qemu-iotests/139 | 12 +- tests/qemu-iotests/182 | 13 +- 7 files changed, 936 insertions(+), 7 deletions(-) create mode 100644 tests/qemu-iotests/051.s390-ccw-virtio.out create mode 100644 tests/qemu-iotests/067.s390-ccw-virtio.out
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). Cornelia Huck (3): iotests: use -ccw on s390x for 040, 139, and 182 iotests: use -ccw on s390x for 051 iotests: use -ccw on s390x for 067 tests/qemu-iotests/040 | 6 +- tests/qemu-iotests/051 | 9 +- tests/qemu-iotests/051.s390-ccw-virtio.out | 434 +++++++++++++++++++++++++++ tests/qemu-iotests/067 | 11 +- tests/qemu-iotests/067.s390-ccw-virtio.out | 458 +++++++++++++++++++++++++++++ tests/qemu-iotests/139 | 12 +- tests/qemu-iotests/182 | 13 +- 7 files changed, 936 insertions(+), 7 deletions(-) create mode 100644 tests/qemu-iotests/051.s390-ccw-virtio.out create mode 100644 tests/qemu-iotests/067.s390-ccw-virtio.out -- 2.13.5
在 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. How do you think this? :-) Thanks! > > Cornelia Huck (3): > iotests: use -ccw on s390x for 040, 139, and 182 > iotests: use -ccw on s390x for 051 > iotests: use -ccw on s390x for 067 > > tests/qemu-iotests/040 | 6 +- > tests/qemu-iotests/051 | 9 +- > tests/qemu-iotests/051.s390-ccw-virtio.out | 434 +++++++++++++++++++++++++++ > tests/qemu-iotests/067 | 11 +- > tests/qemu-iotests/067.s390-ccw-virtio.out | 458 +++++++++++++++++++++++++++++ > tests/qemu-iotests/139 | 12 +- > tests/qemu-iotests/182 | 13 +- > 7 files changed, 936 insertions(+), 7 deletions(-) > create mode 100644 tests/qemu-iotests/051.s390-ccw-virtio.out > create mode 100644 tests/qemu-iotests/067.s390-ccw-virtio.out > -- Regards QingFeng Hao
On Wed, 6 Sep 2017 14:57:48 +0800 QingFeng Hao <haoqf@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. > How do you think this? :-) I can take a look at this. But I think we want to prefer ccw for s390x in the tests in any case, for the reasons stated above. > Thanks! > > > > > Cornelia Huck (3): > > iotests: use -ccw on s390x for 040, 139, and 182 > > iotests: use -ccw on s390x for 051 > > iotests: use -ccw on s390x for 067 > > > > tests/qemu-iotests/040 | 6 +- > > tests/qemu-iotests/051 | 9 +- > > tests/qemu-iotests/051.s390-ccw-virtio.out | 434 +++++++++++++++++++++++++++ > > tests/qemu-iotests/067 | 11 +- > > tests/qemu-iotests/067.s390-ccw-virtio.out | 458 +++++++++++++++++++++++++++++ > > tests/qemu-iotests/139 | 12 +- > > tests/qemu-iotests/182 | 13 +- > > 7 files changed, 936 insertions(+), 7 deletions(-) > > create mode 100644 tests/qemu-iotests/051.s390-ccw-virtio.out > > create mode 100644 tests/qemu-iotests/067.s390-ccw-virtio.out > > >
On Wed, 6 Sep 2017 14:57:48 +0800 QingFeng Hao <haoqf@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).
在 2017/9/6 下午3:59, Cornelia Huck 写道: > On Wed, 6 Sep 2017 14:57:48 +0800 > QingFeng Hao <haoqf@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. Oh. Yes, that makes sense. Actually the first way we thought about was change the code not change the testcases. Thanks for your 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). Agree. > >
© 2016 - 2024 Red Hat, Inc.