On Thu, 14 Nov 2019 14:02:35 +0100 Halil Pasic <pa...@linux.ibm.com> wrote:
> On Thu, 14 Nov 2019 11:38:23 +0100 > Cornelia Huck <coh...@redhat.com> wrote: > > > On Wed, 13 Nov 2019 20:02:33 +0100 > > Pierre Morel <pmo...@linux.ibm.com> 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? > > > > >
