There were some missing checks. There might be some more missing. For details, see the individual patches. Regarding testing: did not do much more than a simple smoke test with virtio-ccw. Halil Pasic (2): s390x/css: check ccw address validity s390x/css: fix bits must be zero check for TIC hw/s390x/css.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) -- 2.11.2
On Wed, 26 Jul 2017 00:44:40 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > There were some missing checks. There might be some more missing. For details, > see the individual patches. The checks are not perfect? Colour me shocked ;) > > Regarding testing: did not do much more than a simple smoke test > with virtio-ccw. I think we need a way to throw random channel programs at a channel device... > > Halil Pasic (2): > s390x/css: check ccw address validity > s390x/css: fix bits must be zero check for TIC > > hw/s390x/css.c | 21 ++++++++++++++++++++- > 1 file changed, 20 insertions(+), 1 deletion(-) >
On 07/27/2017 10:26 AM, Cornelia Huck wrote: > On Wed, 26 Jul 2017 00:44:40 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> There were some missing checks. There might be some more missing. For details, >> see the individual patches. > > The checks are not perfect? Colour me shocked ;) > With a fedora or without ;)? >> >> Regarding testing: did not do much more than a simple smoke test >> with virtio-ccw. > > I think we need a way to throw random channel programs at a channel > device... > By random do you mean random random, or do you mean carefully crafted to provoke (and verify) certain responses. If it's more like the second case I've actually wrote something (a kernel driver) for 'internal use' but at the moment it's limited to indirect data access support (no test cases for invalid invalid channel programs). The 'internal guys' say it probably ain't interesting for the rest of the world make this external, but if you are interested I could send you the patch these days. Regards, Halil >> >> Halil Pasic (2): >> s390x/css: check ccw address validity >> s390x/css: fix bits must be zero check for TIC >> >> hw/s390x/css.c | 21 ++++++++++++++++++++- >> 1 file changed, 20 insertions(+), 1 deletion(-) >> > >
[Re-posting my previous reply because I've accidentally dropped almost all addresses.] On 07/27/2017 10:26 AM, Cornelia Huck wrote: > On Wed, 26 Jul 2017 00:44:40 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> There were some missing checks. There might be some more missing. For details, >> see the individual patches. > > The checks are not perfect? Colour me shocked ;) > With a fedora or without ;)? >> >> Regarding testing: did not do much more than a simple smoke test >> with virtio-ccw. > > I think we need a way to throw random channel programs at a channel > device... > By random do you mean random random, or do you mean carefully crafted to provoke (and verify) certain responses. If it's more like the second case I've actually wrote something (a kernel driver) for 'internal use' but at the moment it's limited to indirect data access support (no test cases for invalid invalid channel programs). The 'internal guys' say it probably ain't interesting for the rest of the world make this external, but if you are interested I could send you the patch these days. Regards, Halil >> >> Halil Pasic (2): >> s390x/css: check ccw address validity >> s390x/css: fix bits must be zero check for TIC >> >> hw/s390x/css.c | 21 ++++++++++++++++++++- >> 1 file changed, 20 insertions(+), 1 deletion(-) >> > >
On Thu, 27 Jul 2017 15:18:01 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > [Re-posting my previous reply because I've accidentally > dropped almost all addresses.] > > On 07/27/2017 10:26 AM, Cornelia Huck wrote: > > On Wed, 26 Jul 2017 00:44:40 +0200 > > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> Regarding testing: did not do much more than a simple smoke test > >> with virtio-ccw. > > > > I think we need a way to throw random channel programs at a channel > > device... > > > > By random do you mean random random, or do you mean carefully crafted > to provoke (and verify) certain responses. If it's more like the second > case I've actually wrote something (a kernel driver) for 'internal use' > but at the moment it's limited to indirect data access support (no test > cases for invalid invalid channel programs). That's what I've been thinking of. Standalone guest code would be even better (can be integrated into automatic testing), but it's certainly useful. > The 'internal guys' say it > probably ain't interesting for the rest of the world make this external, > but if you are interested I could send you the patch these days. Would be great if you could make this available. It is especially interesting for me, but possibly for other folks working on s390 as well. Might be good together with an "eat this" channel device in qemu.
On 07/27/2017 03:40 PM, Cornelia Huck wrote: > On Thu, 27 Jul 2017 15:18:01 +0200 > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >> [Re-posting my previous reply because I've accidentally >> dropped almost all addresses.] >> >> On 07/27/2017 10:26 AM, Cornelia Huck wrote: >>> On Wed, 26 Jul 2017 00:44:40 +0200 >>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > >>>> Regarding testing: did not do much more than a simple smoke test >>>> with virtio-ccw. >>> >>> I think we need a way to throw random channel programs at a channel >>> device... >>> >> >> By random do you mean random random, or do you mean carefully crafted >> to provoke (and verify) certain responses. If it's more like the second >> case I've actually wrote something (a kernel driver) for 'internal use' >> but at the moment it's limited to indirect data access support (no test >> cases for invalid invalid channel programs). > > That's what I've been thinking of. Standalone guest code would be even > better (can be integrated into automatic testing), but it's certainly > useful. > >> The 'internal guys' say it >> probably ain't interesting for the rest of the world make this external, >> but if you are interested I could send you the patch these days. > > Would be great if you could make this available. It is especially > interesting for me, but possibly for other folks working on s390 as well. It is very wip and I don't feel comfortable with sharing it with the world yet. But I'm definitely interested in making this available. I haven't figured out what would be the best way to make it available, and I hope you can help me with that. > > Might be good together with an "eat this" channel device in qemu. > If course I do have a qemu counterpart. To sum it up, one I'm done with the next iteration I'm gonna send you with the patches unless you say otherwise. Regards, Halil
On Thu, 27 Jul 2017 15:52:23 +0200 Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > On 07/27/2017 03:40 PM, Cornelia Huck wrote: > > On Thu, 27 Jul 2017 15:18:01 +0200 > > Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > >> [Re-posting my previous reply because I've accidentally > >> dropped almost all addresses.] > >> > >> On 07/27/2017 10:26 AM, Cornelia Huck wrote: > >>> On Wed, 26 Jul 2017 00:44:40 +0200 > >>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote: > > > >>>> Regarding testing: did not do much more than a simple smoke test > >>>> with virtio-ccw. > >>> > >>> I think we need a way to throw random channel programs at a channel > >>> device... > >>> > >> > >> By random do you mean random random, or do you mean carefully crafted > >> to provoke (and verify) certain responses. If it's more like the second > >> case I've actually wrote something (a kernel driver) for 'internal use' > >> but at the moment it's limited to indirect data access support (no test > >> cases for invalid invalid channel programs). > > > > That's what I've been thinking of. Standalone guest code would be even > > better (can be integrated into automatic testing), but it's certainly > > useful. > > > >> The 'internal guys' say it > >> probably ain't interesting for the rest of the world make this external, > >> but if you are interested I could send you the patch these days. > > > > Would be great if you could make this available. It is especially > > interesting for me, but possibly for other folks working on s390 as well. > > It is very wip and I don't feel comfortable with sharing it > with the world yet. But I'm definitely interested in making this > available. I haven't figured out what would be the best way to make > it available, and I hope you can help me with that. Do you have a git tree somewhere you can dump it? > > > > > Might be good together with an "eat this" channel device in qemu. > > > > If course I do have a qemu counterpart. And of course I'd love to see that as well :) > > To sum it up, one I'm done with the next iteration I'm gonna send > you with the patches unless you say otherwise. > > Regards, > Halil >
© 2016 - 2024 Red Hat, Inc.