From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>,
Greg Kurz <groug@kaod.org>
Subject: Re: qtest with multiple driver instances
Date: Thu, 24 Sep 2020 16:06:54 +0200 [thread overview]
Message-ID: <1695852.LfDqFqZZbD@silver> (raw)
In-Reply-To: <7ae8f0cc-021e-d982-4d1d-a46afc37bf28@redhat.com>
On Donnerstag, 24. September 2020 15:50:43 CEST Thomas Huth wrote:
> On 24/09/2020 13.57, Christian Schoenebeck wrote:
> > Hi,
> >
> > I'm currently puzzled with what looks like a limitation of the qtest
> > infrastructure: am I right that it's not possible to use multiple
> > instances of the same driver with qtests?
> >
> > Purpose: I need to add test cases for the 9p 'local' fs driver. So far we
> > only have 9p qtests using the 'synth' fs driver. The problem is, both
> > driver instances would pop up with the same QEMU driver name
> > ("virtio-9p-pci"), and AFAICS qtests in general reference their driver
> > instance by driver name only, which must be a) a unique driver name and
> > b) must match the official QEMU driver name and c) all qtest driver
> > instances are in a global space for all qtests.
> >
> > Is there any workaround or something that I didn't see? Like letting
> > qtests
> > reference a driver instance by PCI address or something?
> >
> > Right now the only option that I see is a hack: forcing one driver
> > instance to use a different bus system like e.g. -> "virtio-9p-ccw" vs.
> > "virtio-9p-pci".
> >
> > Any hint appreciated!
>
> I assume you are referring to the "qos" framework within the qtests? I
> hope Laurent, Paolo or Emanuele can help with that question (now all on
> CC:)...
>
> Thomas
Yes, it looks like it is based on the qos subsystem underneath, i.e.:
tests/qtest/libqos/qgraph.h
Maybe I can use qos_node_contains() to make 2 "virtio-9p-pci" driver instances
accessible for different qtests? It just seems there is no existing code doing
that already, otherwise I could just copy & paste.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-09-24 14:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 11:57 qtest with multiple driver instances Christian Schoenebeck
2020-09-24 13:50 ` Thomas Huth
2020-09-24 14:06 ` Christian Schoenebeck [this message]
2020-09-24 14:27 ` Paolo Bonzini
2020-09-24 17:39 ` Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1695852.LfDqFqZZbD@silver \
--to=qemu_oss@crudebyte.com \
--cc=e.emanuelegiuseppe@gmail.com \
--cc=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.