| Message ID | 20170905111645.18068-6-pasic@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 5 Sep 2017 13:16:45 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > Add a fake device meant for testing the correctness of our css emulation. > > What we currently have is writing a Fibonacci sequence of uint32_t to the > device via ccw write. The write is going to fail if it ain't a Fibonacci > and indicate a device exception in scsw together with the proper residual > count. > > Of course lot's of invalid inputs (besides basic data processing) can be > tested with that as well. > > Usage: > 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 > on the command line > 2) exercise the device from the guest > > Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > --- > > It may not make sense to merge this work in the current form, as it is > solely for test purposes. > --- > hw/s390x/Makefile.objs | 1 + > hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 180 insertions(+) > create mode 100644 hw/s390x/ccw-tester.c The main problem here is that you want to exercise a middle layer (the css code) and need to write boilerplate code on both host and guest side in order to be able to do so. In general, a device that accepts arbitrary channel programs looks useful for testing purposes. I would split out processing of expected responses out, though, so that it can be more easily reused for different use cases. (I dimly recall other test devices...) For the guest tester: Can that be done via the qtest infrastructure somehow?
On 09/06/2017 03:18 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:45 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> Add a fake device meant for testing the correctness of our css emulation. >> >> What we currently have is writing a Fibonacci sequence of uint32_t to the >> device via ccw write. The write is going to fail if it ain't a Fibonacci >> and indicate a device exception in scsw together with the proper residual >> count. >> >> Of course lot's of invalid inputs (besides basic data processing) can be >> tested with that as well. >> >> Usage: >> 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 >> on the command line >> 2) exercise the device from the guest >> >> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> >> --- >> >> It may not make sense to merge this work in the current form, as it is >> solely for test purposes. >> --- >> hw/s390x/Makefile.objs | 1 + >> hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 180 insertions(+) >> create mode 100644 hw/s390x/ccw-tester.c > > The main problem here is that you want to exercise a middle layer (the > css code) and need to write boilerplate code on both host and guest > side in order to be able to do so. > Nod. > In general, a device that accepts arbitrary channel programs looks > useful for testing purposes. I would split out processing of expected > responses out, though, so that it can be more easily reused for > different use cases. > I'm not sure what do you mean here. Could you clarify please? > (I dimly recall other test devices...) > What's on your mind? How do these relate to our problem? Can you give me some pointers? > For the guest tester: Can that be done via the qtest infrastructure > somehow? > Well, for now I have the out-of-tree Linux kernel module provided in the cover letter of the series (you did not comment on that one yet). I think for building trust regarding my IDA implementation it should be able to do the job. Don't you agree? Just a couple of hours ago Janosch (cc-ing Janosch) came to my office, and told be that he is working on CCW-tests for zonk (a minimal kernel for testing -- internal tool AFAIR). By qtest you mean libqtest/libqos? I'm not familiar with that and have no idea what do we have for s390x. I see on libqos-s390x file in test/libqos for starters. Regards, Halil
On Wed, 6 Sep 2017 16:24:13 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > On 09/06/2017 03:18 PM, Cornelia Huck wrote: > > On Tue, 5 Sep 2017 13:16:45 +0200 > > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > >> Add a fake device meant for testing the correctness of our css emulation. > >> > >> What we currently have is writing a Fibonacci sequence of uint32_t to the > >> device via ccw write. The write is going to fail if it ain't a Fibonacci > >> and indicate a device exception in scsw together with the proper residual > >> count. > >> > >> Of course lot's of invalid inputs (besides basic data processing) can be > >> tested with that as well. > >> > >> Usage: > >> 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 > >> on the command line > >> 2) exercise the device from the guest > >> > >> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > >> --- > >> > >> It may not make sense to merge this work in the current form, as it is > >> solely for test purposes. > >> --- > >> hw/s390x/Makefile.objs | 1 + > >> hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ > >> 2 files changed, 180 insertions(+) > >> create mode 100644 hw/s390x/ccw-tester.c > > > > The main problem here is that you want to exercise a middle layer (the > > css code) and need to write boilerplate code on both host and guest > > side in order to be able to do so. > > > > Nod. > > > In general, a device that accepts arbitrary channel programs looks > > useful for testing purposes. I would split out processing of expected > > responses out, though, so that it can be more easily reused for > > different use cases. > > > > I'm not sure what do you mean here. Could you clarify please? Maybe doing things like logging received ccws and responses etc. and and then comparing against an expected outcome. You should be able to write test cases for different sets of things to be tested. I know this is awfully vague :) > > > (I dimly recall other test devices...) > > > > What's on your mind? How do these relate to our problem? Can you > give me some pointers? I was thinking of precedent for test devices... but as said, I only recall this very dimly. > > > For the guest tester: Can that be done via the qtest infrastructure > > somehow? > > > > Well, for now I have the out-of-tree Linux kernel module provided in the > cover letter of the series (you did not comment on that one yet). Yes, I saw that, but have not yet looked at it. If there is a way to do it without too many extra parts, I'd prefer that. > > I think for building trust regarding my IDA implementation it should be > able to do the job. Don't you agree? There's nothing wrong with your test. But we really should try to move to some kind of unified testing that is hopefully self-contained so that interested people can just play with it within the context of qemu. > > Just a couple of hours ago Janosch (cc-ing Janosch) came to my office, > and told be that he is working on CCW-tests for zonk (a minimal kernel > for testing -- internal tool AFAIR). > > By qtest you mean libqtest/libqos? I'm not familiar with that and have no > idea what do we have for s390x. I see on libqos-s390x file in test/libqos > for starters. Yes, that was what I was thinking about. Integrating into what is already there is what we should aim for. [For things that are done via kvm, kvm unit tests are good. But I think we can do css tests completely within qemu.]
On 09/06/2017 05:20 PM, Cornelia Huck wrote: > On Wed, 6 Sep 2017 16:24:13 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> On 09/06/2017 03:18 PM, Cornelia Huck wrote: >>> On Tue, 5 Sep 2017 13:16:45 +0200 >>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: >>> >>>> Add a fake device meant for testing the correctness of our css emulation. >>>> >>>> What we currently have is writing a Fibonacci sequence of uint32_t to the >>>> device via ccw write. The write is going to fail if it ain't a Fibonacci >>>> and indicate a device exception in scsw together with the proper residual >>>> count. >>>> >>>> Of course lot's of invalid inputs (besides basic data processing) can be >>>> tested with that as well. >>>> >>>> Usage: >>>> 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 >>>> on the command line >>>> 2) exercise the device from the guest >>>> >>>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> >>>> --- >>>> >>>> It may not make sense to merge this work in the current form, as it is >>>> solely for test purposes. >>>> --- >>>> hw/s390x/Makefile.objs | 1 + >>>> hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 180 insertions(+) >>>> create mode 100644 hw/s390x/ccw-tester.c >>> >>> The main problem here is that you want to exercise a middle layer (the >>> css code) and need to write boilerplate code on both host and guest >>> side in order to be able to do so. >>> >> >> Nod. >> >>> In general, a device that accepts arbitrary channel programs looks >>> useful for testing purposes. I would split out processing of expected >>> responses out, though, so that it can be more easily reused for >>> different use cases. >>> >> >> I'm not sure what do you mean here. Could you clarify please? > > Maybe doing things like logging received ccws and responses etc. and > and then comparing against an expected outcome. You should be able to > write test cases for different sets of things to be tested. I know this > is awfully vague :) Yes it does sound awfully vague :). In my case different tests are actually done in the kernel module implementing a driver for this device. I compare the expected outcome and the actual outcome there. This device is just a back-end lending itself to experimentation. > >> >>> (I dimly recall other test devices...) >>> >> >> What's on your mind? How do these relate to our problem? Can you >> give me some pointers? > > I was thinking of precedent for test devices... but as said, I only > recall this very dimly. > >> >>> For the guest tester: Can that be done via the qtest infrastructure >>> somehow? >>> >> >> Well, for now I have the out-of-tree Linux kernel module provided in the >> cover letter of the series (you did not comment on that one yet). > > Yes, I saw that, but have not yet looked at it. If there is a way to do > it without too many extra parts, I'd prefer that. > Well, I think the module is almost as economical with extra parts as it can get: it uses the kernel infrastructure and does not do a whole lot of things on top. I think it's worth a look. I hope it will also give answers to some of the implicit questions I see above. Yes, tests done in the driver are currently very few. Both with and without indirect data access we first let a device consume a Fibonacci sequence and verify that the IO has succeeded. Then we deliberately change an element in the sequence so it ain't the next Fibonacci number. And check for unit exception and proper residual count. With that we are sure that the data was properly consumed up until the given element. For IDA we the shorten the sequence so it does not contain the 'broken' element, and expect completion again. As you see this is a sufficient test for the good path for single CCW programs. Extending to testing chaining (different concern), or responses to broken channel programs (e.g. ORB flags, bad addresses, tic rules) should be quite straightforward. >> >> I think for building trust regarding my IDA implementation it should be >> able to do the job. Don't you agree? > > There's nothing wrong with your test. But we really should try to move > to some kind of unified testing that is hopefully self-contained so > that interested people can just play with it within the context of qemu. > >> >> Just a couple of hours ago Janosch (cc-ing Janosch) came to my office, >> and told be that he is working on CCW-tests for zonk (a minimal kernel >> for testing -- internal tool AFAIR). >> >> By qtest you mean libqtest/libqos? I'm not familiar with that and have no >> idea what do we have for s390x. I see on libqos-s390x file in test/libqos >> for starters. > > Yes, that was what I was thinking about. Integrating into what is > already there is what we should aim for. > > [For things that are done via kvm, kvm unit tests are good. But I think > we can do css tests completely within qemu.] > I agree fully, the point is somebody needs to make it happen. I would be very sad if forced to make it happen for the sake of this patch set. That said. I could not identify any required actions on this front (testing IDA) . If I made a mistake please point it out. I'm gonna try and speak with the folks here about our testing strategy. IMHO libqtest/libqos could very well be a part of it, but I can't tell anything for sure for now. If somebody volunteers to transform what I have in this patch and the cover letter to something better integrated, it will make me more than happy. Regards, Halil
* Cornelia Huck <cohuck@redhat.com> [2017-09-06 15:18:21 +0200]: > On Tue, 5 Sep 2017 13:16:45 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > Add a fake device meant for testing the correctness of our css emulation. > > > > What we currently have is writing a Fibonacci sequence of uint32_t to the > > device via ccw write. The write is going to fail if it ain't a Fibonacci > > and indicate a device exception in scsw together with the proper residual > > count. > > > > Of course lot's of invalid inputs (besides basic data processing) can be > > tested with that as well. > > > > Usage: > > 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 > > on the command line > > 2) exercise the device from the guest > > > > Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > > --- > > > > It may not make sense to merge this work in the current form, as it is > > solely for test purposes. > > --- > > hw/s390x/Makefile.objs | 1 + > > hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 180 insertions(+) > > create mode 100644 hw/s390x/ccw-tester.c > > The main problem here is that you want to exercise a middle layer (the > css code) and need to write boilerplate code on both host and guest > side in order to be able to do so. > > In general, a device that accepts arbitrary channel programs looks > useful for testing purposes. I would split out processing of expected > responses out, though, so that it can be more easily reused for > different use cases. > > (I dimly recall other test devices...) > > For the guest tester: Can that be done via the qtest infrastructure > somehow? > 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?
On Wed, 6 Sep 2017 18:16:29 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > On 09/06/2017 05:20 PM, Cornelia Huck wrote: > > On Wed, 6 Sep 2017 16:24:13 +0200 > > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > >> On 09/06/2017 03:18 PM, Cornelia Huck wrote: > >>> On Tue, 5 Sep 2017 13:16:45 +0200 > >>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >>> > >>>> Add a fake device meant for testing the correctness of our css emulation. > >>>> > >>>> What we currently have is writing a Fibonacci sequence of uint32_t to the > >>>> device via ccw write. The write is going to fail if it ain't a Fibonacci > >>>> and indicate a device exception in scsw together with the proper residual > >>>> count. > >>>> > >>>> Of course lot's of invalid inputs (besides basic data processing) can be > >>>> tested with that as well. > >>>> > >>>> Usage: > >>>> 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 > >>>> on the command line > >>>> 2) exercise the device from the guest > >>>> > >>>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > >>>> --- > >>>> > >>>> It may not make sense to merge this work in the current form, as it is > >>>> solely for test purposes. > >>>> --- > >>>> hw/s390x/Makefile.objs | 1 + > >>>> hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ > >>>> 2 files changed, 180 insertions(+) > >>>> create mode 100644 hw/s390x/ccw-tester.c > >>> > >>> The main problem here is that you want to exercise a middle layer (the > >>> css code) and need to write boilerplate code on both host and guest > >>> side in order to be able to do so. > >>> > >> > >> Nod. > >> > >>> In general, a device that accepts arbitrary channel programs looks > >>> useful for testing purposes. I would split out processing of expected > >>> responses out, though, so that it can be more easily reused for > >>> different use cases. > >>> > >> > >> I'm not sure what do you mean here. Could you clarify please? > > > > Maybe doing things like logging received ccws and responses etc. and > > and then comparing against an expected outcome. You should be able to > > write test cases for different sets of things to be tested. I know this > > is awfully vague :) > > Yes it does sound awfully vague :). In my case different tests are > actually done in the kernel module implementing a driver for this > device. I compare the expected outcome and the actual outcome there. > This device is just a back-end lending itself to experimentation. I think we want both guest-side and host-side checking. I think we should aim for a guest-side checker that does not require a kernel module (a simple guest makes it easier to run as an automated test.) > >>> For the guest tester: Can that be done via the qtest infrastructure > >>> somehow? > >>> > >> > >> Well, for now I have the out-of-tree Linux kernel module provided in the > >> cover letter of the series (you did not comment on that one yet). > > > > Yes, I saw that, but have not yet looked at it. If there is a way to do > > it without too many extra parts, I'd prefer that. > > > > Well, I think the module is almost as economical with extra parts as it > can get: it uses the kernel infrastructure and does not do a whole lot > of things on top. And that's also the problem: You drag the whole kernel infrastructure along with it. > > I think it's worth a look. It certainly is, but you know how it is with resources... > I hope it will also give answers to some > of the implicit questions I see above. Yes, tests done in the driver > are currently very few. Both with and without indirect data access > we first let a device consume a Fibonacci sequence and verify that > the IO has succeeded. Then we deliberately change an element in the > sequence so it ain't the next Fibonacci number. And check for unit > exception and proper residual count. With that we are sure that > the data was properly consumed up until the given element. For IDA > we the shorten the sequence so it does not contain the 'broken' > element, and expect completion again. As you see this is a sufficient > test for the good path for single CCW programs. > > Extending to testing chaining (different concern), or responses > to broken channel programs (e.g. ORB flags, bad addresses, tic > rules) should be quite straightforward. Yes, that all sounds very nice. We just disagree about the means :) > > >> > >> I think for building trust regarding my IDA implementation it should be > >> able to do the job. Don't you agree? > > > > There's nothing wrong with your test. But we really should try to move > > to some kind of unified testing that is hopefully self-contained so > > that interested people can just play with it within the context of qemu. > > > >> > >> Just a couple of hours ago Janosch (cc-ing Janosch) came to my office, > >> and told be that he is working on CCW-tests for zonk (a minimal kernel > >> for testing -- internal tool AFAIR). > >> > >> By qtest you mean libqtest/libqos? I'm not familiar with that and have no > >> idea what do we have for s390x. I see on libqos-s390x file in test/libqos > >> for starters. > > > > Yes, that was what I was thinking about. Integrating into what is > > already there is what we should aim for. > > > > [For things that are done via kvm, kvm unit tests are good. But I think > > we can do css tests completely within qemu.] > > > > I agree fully, the point is somebody needs to make it happen. I would > be very sad if forced to make it happen for the sake of this patch set. You must have misunderstood me: This is not a requirement for this patch set... > > That said. I could not identify any required actions on this front (testing > IDA) . If I made a mistake please point it out. I'm gonna try and speak > with the folks here about our testing strategy. IMHO libqtest/libqos could > very well be a part of it, but I can't tell anything for sure for now. Yes, it would be great if we could get something that benefits everyone. If we have tests that integrate into existing infrastructure, it is more likely that they will actually be run :) > > If somebody volunteers to transform what I have in this patch and the > cover letter to something better integrated, it will make me more than > happy. Me too :)
On Thu, 7 Sep 2017 15:31:09 +0800 Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > * Cornelia Huck <cohuck@redhat.com> [2017-09-06 15:18:21 +0200]: > > > On Tue, 5 Sep 2017 13:16:45 +0200 > > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > > > Add a fake device meant for testing the correctness of our css emulation. > > > > > > What we currently have is writing a Fibonacci sequence of uint32_t to the > > > device via ccw write. The write is going to fail if it ain't a Fibonacci > > > and indicate a device exception in scsw together with the proper residual > > > count. > > > > > > Of course lot's of invalid inputs (besides basic data processing) can be > > > tested with that as well. > > > > > > Usage: > > > 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 > > > on the command line > > > 2) exercise the device from the guest > > > > > > Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> > > > --- > > > > > > It may not make sense to merge this work in the current form, as it is > > > solely for test purposes. > > > --- > > > hw/s390x/Makefile.objs | 1 + > > > hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ > > > 2 files changed, 180 insertions(+) > > > create mode 100644 hw/s390x/ccw-tester.c > > > > The main problem here is that you want to exercise a middle layer (the > > css code) and need to write boilerplate code on both host and guest > > side in order to be able to do so. > > > > In general, a device that accepts arbitrary channel programs looks > > useful for testing purposes. I would split out processing of expected > > responses out, though, so that it can be more easily reused for > > different use cases. > > > > (I dimly recall other test devices...) > > > > For the guest tester: Can that be done via the qtest infrastructure > > somehow? > > > > 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.
[...] >>>>> The main problem here is that you want to exercise a middle layer (the >>>>> css code) and need to write boilerplate code on both host and guest >>>>> side in order to be able to do so. >>>>> >>>> >>>> Nod. >>>> >>>>> In general, a device that accepts arbitrary channel programs looks >>>>> useful for testing purposes. I would split out processing of expected >>>>> responses out, though, so that it can be more easily reused for >>>>> different use cases. >>>>> >>>> >>>> I'm not sure what do you mean here. Could you clarify please? >>> >>> Maybe doing things like logging received ccws and responses etc. and >>> and then comparing against an expected outcome. You should be able to >>> write test cases for different sets of things to be tested. I know this >>> is awfully vague :) >> >> Yes it does sound awfully vague :). In my case different tests are >> actually done in the kernel module implementing a driver for this >> device. I compare the expected outcome and the actual outcome there. >> This device is just a back-end lending itself to experimentation. > > I think we want both guest-side and host-side checking. I think we > should aim for a guest-side checker that does not require a kernel > module (a simple guest makes it easier to run as an automated test.) Sure, that would be great. The thing is that I want to test the subchannel and not the device and therefore I really do not want to have to issue control commands to a device in order to get data. Having a device that reads and writes without a lot of overhead (like this) is therefore my main target. Where this device lives doesn't concern me and as I'm new to this wonderful IO system take my statements with some salt. :) >>>>> For the guest tester: Can that be done via the qtest infrastructure >>>>> somehow? >>>>> >>>> >>>> Well, for now I have the out-of-tree Linux kernel module provided in the >>>> cover letter of the series (you did not comment on that one yet). >>> >>> Yes, I saw that, but have not yet looked at it. If there is a way to do >>> it without too many extra parts, I'd prefer that. >>> >> >> Well, I think the module is almost as economical with extra parts as it >> can get: it uses the kernel infrastructure and does not do a whole lot >> of things on top. > > And that's also the problem: You drag the whole kernel infrastructure > along with i > >> >> I think it's worth a look. > > It certainly is, but you know how it is with resources... Yes it is and we certainly want to be integrated in as much external testing as possible. It seems like a few people began to run into the same direction but chose different approaches. My zonk test intentions are mainly to get a understanding how this all works without having to use the Linux devices but getting my hands dirty with the instructions and structures. I see your arguments and we'll look into it and discuss consolidating our efforts.
On 09/07/2017 10:08 AM, Cornelia Huck wrote: > On Thu, 7 Sep 2017 15:31:09 +0800 > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > >> * Cornelia Huck <cohuck@redhat.com> [2017-09-06 15:18:21 +0200]: >> >>> On Tue, 5 Sep 2017 13:16:45 +0200 >>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: >>> >>>> Add a fake device meant for testing the correctness of our css emulation. >>>> >>>> What we currently have is writing a Fibonacci sequence of uint32_t to the >>>> device via ccw write. The write is going to fail if it ain't a Fibonacci >>>> and indicate a device exception in scsw together with the proper residual >>>> count. >>>> >>>> Of course lot's of invalid inputs (besides basic data processing) can be >>>> tested with that as well. >>>> >>>> Usage: >>>> 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 >>>> on the command line >>>> 2) exercise the device from the guest >>>> >>>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> >>>> --- >>>> >>>> It may not make sense to merge this work in the current form, as it is >>>> solely for test purposes. >>>> --- >>>> hw/s390x/Makefile.objs | 1 + >>>> hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 180 insertions(+) >>>> create mode 100644 hw/s390x/ccw-tester.c >>> >>> The main problem here is that you want to exercise a middle layer (the >>> css code) and need to write boilerplate code on both host and guest >>> side in order to be able to do so. >>> >>> In general, a device that accepts arbitrary channel programs looks >>> useful for testing purposes. I would split out processing of expected >>> responses out, though, so that it can be more easily reused for >>> different use cases. >>> >>> (I dimly recall other test devices...) >>> >>> For the guest tester: Can that be done via the qtest infrastructure >>> somehow? >>> >> >> 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. > I'm afraid that it would not work without some extra work. AFAIR Connie we said that the 3270 does not use any IDA, so I did not touch the 3270 emulation code in QEMU. To make the scenario viable one should convert the 3270 emulation to ccw data stream (unless the original implementation already took care of IDA, which I doubt). Halil
On Thu, 7 Sep 2017 12:21:50 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > On 09/07/2017 10:08 AM, Cornelia Huck wrote: > > On Thu, 7 Sep 2017 15:31:09 +0800 > > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > >> 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. > > > > I'm afraid that it would not work without some extra work. > AFAIR Connie we said that the 3270 does not use any IDA, so > I did not touch the 3270 emulation code in QEMU. To make > the scenario viable one should convert the 3270 emulation > to ccw data stream (unless the original implementation > already took care of IDA, which I doubt). But the vfio-ccw code uses idals... no need to touch the 3270 emulation.
On Thu, 7 Sep 2017 11:10:17 +0200 Janosch Frank <frankja@linux.vnet.ibm.com> wrote: > The thing is that I want to test the subchannel and not the device and > therefore I really do not want to have to issue control commands to a > device in order to get data. Having a device that reads and writes > without a lot of overhead (like this) is therefore my main target. Yes, a simple device backend for the channel subsystem is useful. What could also be useful is a way to inject errors, e.g. randomly failing things and then verifying that a sensible error reaches the guest. These paths are part of the css and not the device, so it makes sense to verify that these are working as expected. (Especially as they aren't usually seen in the wild.) But let's defer that one :) > > Where this device lives doesn't concern me and as I'm new to this > wonderful IO system take my statements with some salt. :) You'll learn to love it 8) > Yes it is and we certainly want to be integrated in as much external > testing as possible. It seems like a few people began to run into the > same direction but chose different approaches. My zonk test intentions > are mainly to get a understanding how this all works without having to > use the Linux devices but getting my hands dirty with the instructions > and structures. Something zonk-like would probably be a good thing for a test setup that can be run via make check or something like that. > > I see your arguments and we'll look into it and discuss consolidating > our efforts. Great, thanks for doing that!
* Cornelia Huck <cohuck@redhat.com> [2017-09-07 12:52:20 +0200]: > On Thu, 7 Sep 2017 12:21:50 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > On 09/07/2017 10:08 AM, Cornelia Huck wrote: > > > On Thu, 7 Sep 2017 15:31:09 +0800 > > > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > > > >> 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. > > > > > > > I'm afraid that it would not work without some extra work. > > AFAIR Connie we said that the 3270 does not use any IDA, so > > I did not touch the 3270 emulation code in QEMU. To make > > the scenario viable one should convert the 3270 emulation > > to ccw data stream (unless the original implementation > > already took care of IDA, which I doubt). > > But the vfio-ccw code uses idals... no need to touch the 3270 emulation. > What Halil pointed out is that the ccw_cb implementation of 3270 emulation does not take care of IDALs. This is true. I can also do that right after this series, if Halil agrees. (The 3270 emulation authors are busy of other stuff these days. :()
On 09/08/2017 04:01 AM, Dong Jia Shi wrote: > * Cornelia Huck <cohuck@redhat.com> [2017-09-07 12:52:20 +0200]: > >> On Thu, 7 Sep 2017 12:21:50 +0200 >> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: >> >>> On 09/07/2017 10:08 AM, Cornelia Huck wrote: >>>> On Thu, 7 Sep 2017 15:31:09 +0800 >>>> Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: >> >>>>> 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. >>>> >>> >>> I'm afraid that it would not work without some extra work. >>> AFAIR Connie we said that the 3270 does not use any IDA, so >>> I did not touch the 3270 emulation code in QEMU. To make >>> the scenario viable one should convert the 3270 emulation >>> to ccw data stream (unless the original implementation >>> already took care of IDA, which I doubt). >> >> But the vfio-ccw code uses idals... no need to touch the 3270 emulation. >> > What Halil pointed out is that the ccw_cb implementation of 3270 > emulation does not take care of IDALs. This is true. > > I can also do that right after this series, if Halil agrees. > (The 3270 emulation authors are busy of other stuff these days. :() Generally, yes I agree. If it's trivial I will probably do it myself for v2. I need to do a v2 anyway. Halil
* Halil Pasic <pasic@linux.vnet.ibm.com> [2017-09-08 12:28:03 +0200]: [snip] > > What Halil pointed out is that the ccw_cb implementation of 3270 > > emulation does not take care of IDALs. This is true. > > > > I can also do that right after this series, if Halil agrees. > > (The 3270 emulation authors are busy of other stuff these days. :() > > Generally, yes I agree. If it's trivial I will probably do it myself > for v2. I need to do a v2 anyway. > > Halil I saw you are working on this. So leave it to you. ;)
* Cornelia Huck <cohuck@redhat.com> [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.
On Thu, 21 Sep 2017 16:45:47 +0800 Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > * Cornelia Huck <cohuck@redhat.com> [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?)
* Cornelia Huck <cohuck@redhat.com> [2017-09-21 10:54:02 +0200]: > On Thu, 21 Sep 2017 16:45:47 +0800 > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote: > > > * Cornelia Huck <cohuck@redhat.com> [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? After a debugging, when starting g2, I got the following ccw sequence: 1. CCW_CMD_SENSE_ID 0xe4 [OK] 2. CCW_CMD_NOOP 0x03 [OK] 3. CCW_CMD_SET_VIRTIO_REV 0x83 [OK] 4. CCW_CMD_VDEV_RESET 0x33 [FAILED] So this is still in the phase of setting up the device. > Does it work if you modify the nested guest to use the old > per-subchannel indicators mechanism? It turns out the root reason for the pwrite failure is caused by a bug in the vfio-ccw driver: drivers/s390/cio/vfio_ccw_cp.c: ccwchain_fetch_direct() calls pfn_array_alloc_pin() with a zero @len parameter. So it results in a -EINVAL return. The current code assumes that a valid direct ccw always has its count value not equal to zero. However this is not true at least for the CCW_CMD_VDEV_RESET (0x33) command: (gdb) p/x ccw $5 = {cmd_code = 0x33, flags = 0x4, count = 0x0, cda = 0x0} With a temp fix on this problem, more ccws (e.g. 0x11, 0x12, 0x31, 0x72 ...) could be translated and executed well. But finnaly the qemu process on g1 got a segmentation fault: User process fault: interruption code 0238 ilc:3 in libpthread-2.24.so[3ff84f80000+1b000] Failing address: 000ce330b0b00000 TEID: 000ce330b0b00800 Fault in primary space mode while using user ASCE. AS:000000003b6cc1c7 R3:0000000000000024 Segmentation fault dmesg on g1: [ 18.160413] User process fault: interruption code 0238 ilc:3 in libpthread-2.24.so[3ff84f80000+1b000] [ 18.160462] Failing address: 000ce330b0b00000 TEID: 000ce330b0b00800 [ 18.160463] Fault in primary space mode while using user ASCE. [ 18.160470] AS:000000003b6cc1c7 R3:0000000000000024 [ 18.160476] CPU: 1 PID: 2095 Comm: qemu-system-s39 Not tainted 4.13.0-01250-g6baa298-dirty #58 [ 18.160477] Hardware name: IBM 2964 NC9 704 (KVM/Linux) [ 18.160479] task: 0000000038ac8000 task.stack: 0000000038e4c000 [ 18.160480] User PSW : 0705200180000000 000003ff84f93b8a [ 18.160483] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 [ 18.160486] User GPRS: 0000000000000001 000003ff00000003 0000000104be86b0 0000000104be86c6 [ 18.160487] 0000000000000000 0000000100000001 00000001049efb22 000003ffc5dfe13f [ 18.160489] 000003ff643fee60 0000000000000000 000003ffc5dfe258 000003ff643fe8c8 [ 18.160490] 000003ff855a5000 00000001049cc320 000003ff643fe888 000003ff643fe7e8 [ 18.160503] User Code: 000003ff84f93b7a: c0e5ffffe7cb brasl %r14,3ff84f90b10 000003ff84f93b80: a7f4ffc4 brc 15,3ff84f93b08 #000003ff84f93b84: e5600000ff0c tbegin 0,65292 >000003ff84f93b8a: b2220050 ipm >%r5 000003ff84f93b8e: 8850001c srl %r5,28 000003ff84f93b92: a774001c brc 7,3ff84f93bca 000003ff84f93b96: e30020000012 lt %r0,0(%r2) 000003ff84f93b9c: a784ffb6 brc 8,3ff84f93b08 [ 18.160520] Last Breaking-Event-Address: [ 18.160524] [<00000001046404e6>] 0x1046404e6 The above fault is not caused by vfio-ccw directly I think. So now I need to install gdb stuff on g1, and continuing debugging. But ideas on this are welcomed. ;) > > (I'm also wondering how diag is handled?) Not looking into this yet. :-/ >
* Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> [2017-09-26 15:48:56 +0800]: [...] > > > > > > 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? > After a debugging, when starting g2, I got the following ccw sequence: > 1. CCW_CMD_SENSE_ID 0xe4 [OK] > 2. CCW_CMD_NOOP 0x03 [OK] > 3. CCW_CMD_SET_VIRTIO_REV 0x83 [OK] > 4. CCW_CMD_VDEV_RESET 0x33 [FAILED] > > So this is still in the phase of setting up the device. > > > Does it work if you modify the nested guest to use the old > > per-subchannel indicators mechanism? > It turns out the root reason for the pwrite failure is caused by a bug > in the vfio-ccw driver: > drivers/s390/cio/vfio_ccw_cp.c: ccwchain_fetch_direct() > calls pfn_array_alloc_pin() with a zero @len parameter. > So it results in a -EINVAL return. > > The current code assumes that a valid direct ccw always has its count > value not equal to zero. However this is not true at least for the > CCW_CMD_VDEV_RESET (0x33) command: > (gdb) p/x ccw > $5 = {cmd_code = 0x33, flags = 0x4, count = 0x0, cda = 0x0} > > With a temp fix on this problem, more ccws (e.g. 0x11, 0x12, 0x31, 0x72 > ...) could be translated and executed well. But finnaly the qemu process > on g1 got a segmentation fault: > User process fault: interruption code 0238 ilc:3 in libpthread-2.24.so[3ff84f80000+1b000] > Failing address: 000ce330b0b00000 TEID: 000ce330b0b00800 > Fault in primary space mode while using user ASCE. > AS:000000003b6cc1c7 R3:0000000000000024 > Segmentation fault > > dmesg on g1: > [ 18.160413] User process fault: interruption code 0238 ilc:3 in libpthread-2.24.so[3ff84f80000+1b000] > [ 18.160462] Failing address: 000ce330b0b00000 TEID: 000ce330b0b00800 > [ 18.160463] Fault in primary space mode while using user ASCE. > [ 18.160470] AS:000000003b6cc1c7 R3:0000000000000024 > [ 18.160476] CPU: 1 PID: 2095 Comm: qemu-system-s39 Not tainted 4.13.0-01250-g6baa298-dirty #58 > [ 18.160477] Hardware name: IBM 2964 NC9 704 (KVM/Linux) > [ 18.160479] task: 0000000038ac8000 task.stack: 0000000038e4c000 > [ 18.160480] User PSW : 0705200180000000 000003ff84f93b8a > [ 18.160483] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 > [ 18.160486] User GPRS: 0000000000000001 000003ff00000003 0000000104be86b0 0000000104be86c6 > [ 18.160487] 0000000000000000 0000000100000001 00000001049efb22 000003ffc5dfe13f > [ 18.160489] 000003ff643fee60 0000000000000000 000003ffc5dfe258 000003ff643fe8c8 > [ 18.160490] 000003ff855a5000 00000001049cc320 000003ff643fe888 000003ff643fe7e8 > [ 18.160503] User Code: 000003ff84f93b7a: c0e5ffffe7cb brasl %r14,3ff84f90b10 > 000003ff84f93b80: a7f4ffc4 brc 15,3ff84f93b08 > #000003ff84f93b84: e5600000ff0c tbegin 0,65292 > >000003ff84f93b8a: b2220050 ipm >%r5 > 000003ff84f93b8e: 8850001c srl %r5,28 > 000003ff84f93b92: a774001c brc 7,3ff84f93bca > 000003ff84f93b96: e30020000012 lt %r0,0(%r2) > 000003ff84f93b9c: a784ffb6 brc 8,3ff84f93b08 > [ 18.160520] Last Breaking-Event-Address: > [ 18.160524] [<00000001046404e6>] 0x1046404e6 > > The above fault is not caused by vfio-ccw directly I think. So now I > need to install gdb stuff on g1, and continuing debugging. But ideas on > this are welcomed. ;) Using gdb with Qemu on g1, I got the following information: Thread 3 "qemu-system-s39" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x3ffdcdff910 (LWP 2095)] __lll_lock_elision (futex=0x1007686b0 <qemu_global_mutex>, adapt_count=0x1007686c6 <qemu_global_mutex+22>, private=0) at ../sysdeps/unix/sysv/linux/s390/elision-lock.c:66 66 ../sysdeps/unix/sysv/linux/s390/elision-lock.c: No such file or directory. (gdb) bt #0 __lll_lock_elision (futex=0x1007686b0 <qemu_global_mutex>, adapt_count=0x1007686c6 <qemu_global_mutex+22>, private=0) at ../sysdeps/unix/sysv/linux/s390/elision-lock.c:66 #1 0x000003fffd98a1f4 in __GI___pthread_mutex_lock (mutex=<optimized out>) at ../nptl/pthread_mutex_lock.c:92 #2 0x0000000100515326 in qemu_mutex_lock ( mutex=0x1007686b0 <qemu_global_mutex>) at util/qemu-thread-posix.c:65 #3 0x00000001000f2dec in qemu_mutex_lock_iothread () at /root/qemu/cpus.c:1581 #4 0x000000010022827e in kvm_arch_handle_exit (cs=0x100c30ce0, run=0x3fffce80000) at /root/qemu/target/s390x/kvm.c:2193 #5 0x0000000100131c40 in kvm_cpu_exec (cpu=0x100c30ce0) at /root/qemu/accel/kvm/kvm-all.c:2094 #6 0x00000001000f1d2a in qemu_kvm_cpu_thread_fn (arg=0x100c30ce0) at /root/qemu/cpus.c:1128 #7 0x000003fffd9879d4 in start_thread (arg=0x3ffdcdff910) at pthread_create.c:335 #8 0x000003fffd8736ae in thread_start () at ../sysdeps/unix/sysv/linux/s390/s390-64/clone.S:71 PC not saved Googled lock elision for a while, and I still have no idea on this problem. Any suggestions on this?
diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs index b2aade2466..44a07431da 100644 --- a/hw/s390x/Makefile.objs +++ b/hw/s390x/Makefile.objs @@ -17,3 +17,4 @@ obj-y += s390-stattrib.o obj-$(CONFIG_KVM) += s390-skeys-kvm.o obj-$(CONFIG_KVM) += s390-stattrib-kvm.o obj-y += s390-ccw.o +obj-y += ccw-tester.o diff --git a/hw/s390x/ccw-tester.c b/hw/s390x/ccw-tester.c new file mode 100644 index 0000000000..c8017818c4 --- /dev/null +++ b/hw/s390x/ccw-tester.c @@ -0,0 +1,179 @@ +#include "qemu/osdep.h" +#include "qapi/error.h" +#include "qemu/module.h" +#include "cpu.h" +#include "hw/s390x/css.h" +#include "hw/s390x/css-bridge.h" +#include "hw/s390x/3270-ccw.h" +#include "exec/address-spaces.h" +#include <error.h> + +typedef struct CcwTesterDevice { + CcwDevice parent_obj; + uint16_t cu_type; + uint8_t chpid_type; + struct { + uint32_t ring[4]; + unsigned int next; + } fib; +} CcwTesterDevice; + + +typedef struct CcwTesterClass { + CCWDeviceClass parent_class; + DeviceRealize parent_realize; +} CcwTesterClass; + +#define TYPE_CCW_TESTER "ccw-tester" + +#define CCW_TESTER(obj) \ + OBJECT_CHECK(CcwTesterDevice, (obj), TYPE_CCW_TESTER) +#define CCW_TESTER_CLASS(klass) \ + OBJECT_CLASS_CHECK(CcwTesterClass, (klass), TYPE_CCW_TESTER) +#define CCW_TESTER_GET_CLASS(obj) \ + OBJECT_GET_CLASS(CcwTesterClass, (obj), TYPE_CCW_TESTER) + +#define CCW_CMD_READ 0x01U +#define CCW_CMD_WRITE 0x02U + +static unsigned int abs_to_ring(unsigned int i) +{ + return i & 0x3; +} + +static int ccw_tester_write_fib(SubchDev *sch, CCW1 ccw) +{ + CcwTesterDevice *d = sch->driver_data; + bool is_fib = true; + uint32_t sum; + int ret = 0; + + ccw_dstream_init(&sch->cds, &ccw, &sch->orb); + d->fib.next = 0; + while (ccw_dstream_avail(&sch->cds) > 0) { + ret = ccw_dstream_read(&sch->cds, + d->fib.ring[abs_to_ring(d->fib.next)]); + if (ret) { + error(0, -ret, "fib"); + break; + } + if (d->fib.next > 2) { + sum = (d->fib.ring[abs_to_ring(d->fib.next - 1)] + + d->fib.ring[abs_to_ring(d->fib.next - 2)]); + is_fib = sum == d->fib.ring[abs_to_ring(d->fib.next)]; + if (!is_fib) { + break; + } + } + ++(d->fib.next); + } + if (!is_fib) { + sch->curr_status.scsw.ctrl &= ~SCSW_ACTL_START_PEND; + sch->curr_status.scsw.ctrl |= SCSW_STCTL_PRIMARY | + SCSW_STCTL_SECONDARY | + SCSW_STCTL_ALERT | + SCSW_STCTL_STATUS_PEND; + sch->curr_status.scsw.count = ccw_dstream_residual_count(&sch->cds); + sch->curr_status.scsw.cpa = sch->channel_prog + 8; + sch->curr_status.scsw.dstat = SCSW_DSTAT_UNIT_EXCEP; + return -EIO; + } + return ret; +} + +static int ccw_tester_ccw_cb_impl(SubchDev *sch, CCW1 ccw) +{ + switch (ccw.cmd_code) { + case CCW_CMD_READ: + break; + case CCW_CMD_WRITE: + return ccw_tester_write_fib(sch, ccw); + default: + return -EINVAL; + } + return 0; +} + +static void ccw_tester_realize(DeviceState *ds, Error **errp) +{ + uint16_t chpid; + CcwTesterDevice *dev = CCW_TESTER(ds); + CcwTesterClass *ctc = CCW_TESTER_GET_CLASS(dev); + CcwDevice *cdev = CCW_DEVICE(ds); + BusState *qbus = qdev_get_parent_bus(ds); + VirtualCssBus *cbus = VIRTUAL_CSS_BUS(qbus); + SubchDev *sch; + Error *err = NULL; + + sch = css_create_sch(cdev->devno, true, cbus->squash_mcss, errp); + if (!sch) { + return; + } + + sch->driver_data = dev; + cdev->sch = sch; + chpid = css_find_free_chpid(sch->cssid); + + if (chpid > MAX_CHPID) { + error_setg(&err, "No available chpid to use."); + goto out_err; + } + + sch->id.reserved = 0xff; + sch->id.cu_type = dev->cu_type; + css_sch_build_virtual_schib(sch, (uint8_t)chpid, + dev->chpid_type); + sch->ccw_cb = ccw_tester_ccw_cb_impl; + sch->do_subchannel_work = do_subchannel_work_virtual; + + + ctc->parent_realize(ds, &err); + if (err) { + goto out_err; + } + + css_generate_sch_crws(sch->cssid, sch->ssid, sch->schid, + ds->hotplugged, 1); + return; + +out_err: + error_propagate(errp, err); + css_subch_assign(sch->cssid, sch->ssid, sch->schid, sch->devno, NULL); + cdev->sch = NULL; + g_free(sch); +} + +static Property ccw_tester_properties[] = { + DEFINE_PROP_UINT16("cu_type", CcwTesterDevice, cu_type, + 0x3831), + DEFINE_PROP_UINT8("chpid_type", CcwTesterDevice, chpid_type, + 0x98), + DEFINE_PROP_END_OF_LIST(), +}; + +static void ccw_tester_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + CcwTesterClass *ctc = CCW_TESTER_CLASS(klass); + + dc->props = ccw_tester_properties; + dc->bus_type = TYPE_VIRTUAL_CSS_BUS; + ctc->parent_realize = dc->realize; + dc->realize = ccw_tester_realize; + dc->hotpluggable = false; +} + +static const TypeInfo ccw_tester_info = { + .name = TYPE_CCW_TESTER, + .parent = TYPE_CCW_DEVICE, + .instance_size = sizeof(CcwTesterDevice), + .class_init = ccw_tester_class_init, + .class_size = sizeof(CcwTesterClass), +}; + +static void ccw_tester_register(void) +{ + type_register_static(&ccw_tester_info); +} + +type_init(ccw_tester_register)
Add a fake device meant for testing the correctness of our css emulation. What we currently have is writing a Fibonacci sequence of uint32_t to the device via ccw write. The write is going to fail if it ain't a Fibonacci and indicate a device exception in scsw together with the proper residual count. Of course lot's of invalid inputs (besides basic data processing) can be tested with that as well. Usage: 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 on the command line 2) exercise the device from the guest Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> --- It may not make sense to merge this work in the current form, as it is solely for test purposes. --- hw/s390x/Makefile.objs | 1 + hw/s390x/ccw-tester.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+) create mode 100644 hw/s390x/ccw-tester.c