Re: [PATCH v1] s390x: kvm-unit-tests: a PONG device for Sub Channels tests

[Cornelia Huck]

On Thu, 14 Nov 2019 14:02:35 +0100
Halil Pasic <address@hidden> wrote:

> On Thu, 14 Nov 2019 11:38:23 +0100
> Cornelia Huck <address@hidden> wrote:
> 
> > On Wed, 13 Nov 2019 20:02:33 +0100
> > Pierre Morel <address@hidden> wrote:
> > 
> > Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
> > one consumer :)  
> 
> And subchannel is one word in s390-speak.
> 
> >   
> 
> [..]
> 
> > Some questions regarding this device and its intended usage:
> > 
> > - What are you trying to test? Basic ccw processing, or something more
> >   specific? Is there any way you can use the kvm-unit-test
> >   infrastructure to test basic processing with an existing device?  
> 
> I'm also curious about the big picture (what is in scope and what out
> of scope). Your design should be evaluated in the light of intended
> usage.
> 
> BTW have you had a look at this abandoned patch-set of mine:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04220.html

Do you recall why it was abandoned? Or did we just forget to follow up
on it?

> 
> We made some different design decisions, while aiming essentially for the
> same. Maybe it's due to different scope, maybe not. For instance one
> can't test IDA with PONG, I guess.

Now that I saw this again, I also recall the discussion of comparing it
with the "testdev" for pci/isa. Anybody knows if these are used by
kvm-unit-tests?

> 
> Regards,
> Halil
> 
> > - Who is instantiating this device? Only the kvm-unit-test?
> > - Can you instantiate multiple instances? Does that make sense? If yes,
> >   it should probably not request a new chpid every time :)
> > - What happens if someone instantiates this by hand? The only drawback
> >   is that it uses up a subchannel and a chpid, right?
> > - Do you plan to make this hotpluggable later?
> > 
> >   
>