I've keept the title althogh the scope shifted a bit: it's
more about introducing ccw-testdev than about IDA. The goal
is to facilitate testing the virtual channel subsystem
implementation, and the ccw interpretation.

The first patch is the interesting one. See it's cover letter
for details. The RFC is about discussing some technical issues
with this patch.

The other two patches are an out of source kernel module which
is basically only there so you can try out the first patch. The
tests there should probably be ported to something else. I don't
know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
bios based test image. We still have to figure out that. 

Halil Pasic (3):
  s390x/ccs: add ccw-testdev emulated device
  ccw-tester: a tester device for ccw I/O
  ccw-tester: add tic test

 hw/misc/Makefile.objs |   1 +
 hw/misc/ccw-testdev.c | 284 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/misc/ccw-testdev.h |  18 ++++
 3 files changed, 303 insertions(+)
 create mode 100644 hw/misc/ccw-testdev.c
 create mode 100644 hw/misc/ccw-testdev.h

-- 
2.13.5

ping

On 11/08/2017 05:54 PM, Halil Pasic wrote:
> I've keept the title althogh the scope shifted a bit: it's
> more about introducing ccw-testdev than about IDA. The goal
> is to facilitate testing the virtual channel subsystem
> implementation, and the ccw interpretation.
> 
> The first patch is the interesting one. See it's cover letter
> for details. The RFC is about discussing some technical issues
> with this patch.
> 
> The other two patches are an out of source kernel module which
> is basically only there so you can try out the first patch. The
> tests there should probably be ported to something else. I don't
> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
> bios based test image. We still have to figure out that. 
> 
> Halil Pasic (3):
>   s390x/ccs: add ccw-testdev emulated device
>   ccw-tester: a tester device for ccw I/O
>   ccw-tester: add tic test
> 
>  hw/misc/Makefile.objs |   1 +
>  hw/misc/ccw-testdev.c | 284 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/misc/ccw-testdev.h |  18 ++++
>  3 files changed, 303 insertions(+)
>  create mode 100644 hw/misc/ccw-testdev.c
>  create mode 100644 hw/misc/ccw-testdev.h
> 

On 11/22/2017 03:19 PM, Halil Pasic wrote:
> ping
> 

ping^2

> On 11/08/2017 05:54 PM, Halil Pasic wrote:
>> I've keept the title althogh the scope shifted a bit: it's
>> more about introducing ccw-testdev than about IDA. The goal
>> is to facilitate testing the virtual channel subsystem
>> implementation, and the ccw interpretation.
>>
>> The first patch is the interesting one. See it's cover letter
>> for details. The RFC is about discussing some technical issues
>> with this patch.
>>
>> The other two patches are an out of source kernel module which
>> is basically only there so you can try out the first patch. The
>> tests there should probably be ported to something else. I don't
>> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
>> bios based test image. We still have to figure out that. 
>>
>> Halil Pasic (3):
>>   s390x/ccs: add ccw-testdev emulated device
>>   ccw-tester: a tester device for ccw I/O
>>   ccw-tester: add tic test
>>
>>  hw/misc/Makefile.objs |   1 +
>>  hw/misc/ccw-testdev.c | 284 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  hw/misc/ccw-testdev.h |  18 ++++
>>  3 files changed, 303 insertions(+)
>>  create mode 100644 hw/misc/ccw-testdev.c
>>  create mode 100644 hw/misc/ccw-testdev.h
>>
> 
> 

On 08.11.2017 17:54, Halil Pasic wrote:
> I've keept the title althogh the scope shifted a bit: it's
> more about introducing ccw-testdev than about IDA. The goal
> is to facilitate testing the virtual channel subsystem
> implementation, and the ccw interpretation.
> 
> The first patch is the interesting one. See it's cover letter
> for details. The RFC is about discussing some technical issues
> with this patch.
> 
> The other two patches are an out of source kernel module which
> is basically only there so you can try out the first patch. The
> tests there should probably be ported to something else. I don't
> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
> bios based test image. We still have to figure out that. 

I think both, kvm-unit-tests or qtest+libqos would be good candidates.
Please don't invent a new bios base test image, since kvm-unit-tests
should be very similar already and we really don't need to duplicate
work here.

Anyway, you'd need to add some CSS infracture there first (in both
kvm-unit-tests and the qtest environments), so it's likely a similar
amount of work. qtest has the advantage that it gets checked
automatically during "make check" each time, so I'd have a weak
preference for that one.

 Thomas

On 07.12.2017 07:38, Thomas Huth wrote:
> On 08.11.2017 17:54, Halil Pasic wrote:
>> I've keept the title althogh the scope shifted a bit: it's
>> more about introducing ccw-testdev than about IDA. The goal
>> is to facilitate testing the virtual channel subsystem
>> implementation, and the ccw interpretation.
>>
>> The first patch is the interesting one. See it's cover letter
>> for details. The RFC is about discussing some technical issues
>> with this patch.
>>
>> The other two patches are an out of source kernel module which
>> is basically only there so you can try out the first patch. The
>> tests there should probably be ported to something else. I don't
>> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
>> bios based test image. We still have to figure out that. 
> 
> I think both, kvm-unit-tests or qtest+libqos would be good candidates.
> Please don't invent a new bios base test image, since kvm-unit-tests
> should be very similar already and we really don't need to duplicate
> work here.
> 
> Anyway, you'd need to add some CSS infracture there first (in both
> kvm-unit-tests and the qtest environments), so it's likely a similar
> amount of work. qtest has the advantage that it gets checked
> automatically during "make check" each time, so I'd have a weak
> preference for that one.

Another thought: I'd also like to see the more complex virtio device
qtests enabled for virtio-ccw one day (e.g. tests/virtio-blk-test.c), so
I think we sooner or later should have some CSS infrastructure in the
qtests anyway ==> May I suggest that you have a try with the qtest approach?

 Thanks,
  Thomas

On Thu, 7 Dec 2017 10:01:35 +0100
Thomas Huth <thuth@redhat.com> wrote:

> On 07.12.2017 07:38, Thomas Huth wrote:
> > On 08.11.2017 17:54, Halil Pasic wrote:  
> >> I've keept the title althogh the scope shifted a bit: it's
> >> more about introducing ccw-testdev than about IDA. The goal
> >> is to facilitate testing the virtual channel subsystem
> >> implementation, and the ccw interpretation.
> >>
> >> The first patch is the interesting one. See it's cover letter
> >> for details. The RFC is about discussing some technical issues
> >> with this patch.
> >>
> >> The other two patches are an out of source kernel module which
> >> is basically only there so you can try out the first patch. The
> >> tests there should probably be ported to something else. I don't
> >> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
> >> bios based test image. We still have to figure out that.   
> > 
> > I think both, kvm-unit-tests or qtest+libqos would be good candidates.
> > Please don't invent a new bios base test image, since kvm-unit-tests
> > should be very similar already and we really don't need to duplicate
> > work here.
> > 
> > Anyway, you'd need to add some CSS infracture there first (in both
> > kvm-unit-tests and the qtest environments), so it's likely a similar
> > amount of work. qtest has the advantage that it gets checked
> > automatically during "make check" each time, so I'd have a weak
> > preference for that one.  
> 
> Another thought: I'd also like to see the more complex virtio device
> qtests enabled for virtio-ccw one day (e.g. tests/virtio-blk-test.c), so
> I think we sooner or later should have some CSS infrastructure in the
> qtests anyway ==> May I suggest that you have a try with the qtest approach?

Agreed, this would be helpful to get more ccw coverage in general.

On 12/07/2017 12:53 PM, Cornelia Huck wrote:
> On Thu, 7 Dec 2017 10:01:35 +0100
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> On 07.12.2017 07:38, Thomas Huth wrote:
>>> On 08.11.2017 17:54, Halil Pasic wrote:  
>>>> I've keept the title althogh the scope shifted a bit: it's
>>>> more about introducing ccw-testdev than about IDA. The goal
>>>> is to facilitate testing the virtual channel subsystem
>>>> implementation, and the ccw interpretation.
>>>>
>>>> The first patch is the interesting one. See it's cover letter
>>>> for details. The RFC is about discussing some technical issues
>>>> with this patch.
>>>>
>>>> The other two patches are an out of source kernel module which
>>>> is basically only there so you can try out the first patch. The
>>>> tests there should probably be ported to something else. I don't
>>>> know what: maybe kvm-unit-tests, maybe qtest+libqos, or maybe some
>>>> bios based test image. We still have to figure out that.   
>>>
>>> I think both, kvm-unit-tests or qtest+libqos would be good candidates.
>>> Please don't invent a new bios base test image, since kvm-unit-tests
>>> should be very similar already and we really don't need to duplicate
>>> work here.
>>>
>>> Anyway, you'd need to add some CSS infracture there first (in both
>>> kvm-unit-tests and the qtest environments), so it's likely a similar
>>> amount of work. qtest has the advantage that it gets checked
>>> automatically during "make check" each time, so I'd have a weak
>>> preference for that one.  
>>
>> Another thought: I'd also like to see the more complex virtio device
>> qtests enabled for virtio-ccw one day (e.g. tests/virtio-blk-test.c), so
>> I think we sooner or later should have some CSS infrastructure in the
>> qtests anyway ==> May I suggest that you have a try with the qtest approach?
> 
> Agreed, this would be helpful to get more ccw coverage in general.
> 

Yeah qtest+libqos does seem like the most likely candidate. We
are likely to go down this path. I say we, because it seems likely
that the guest counterpart with the unit test suite is going to
be done by somebody having more time to invest into this.

Regards,
Halil