From: Cornelia Huck <cohuck@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org, kwankhede@nvidia.com,
alex.williamson@redhat.com, mst@redhat.com, tiwei.bie@intel.com,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, zhenyuw@linux.intel.com,
zhi.a.wang@intel.com, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
airlied@linux.ie, daniel@ffwll.ch, farman@linux.ibm.com,
pasic@linux.ibm.com, sebott@linux.ibm.com, oberpar@linux.ibm.com,
heiko.carstens@de.ibm.com, gor@linux.ibm.com,
borntraeger@de.ibm.com, akrowiak@linux.ibm.com,
freude@linux.ibm.com, lingshan.zhu@intel.com, idos@mellanox.com,
eperezma@redhat.com, lulu@redhat.com, parav@mellanox.com,
christophe.de.dinechin@gmail.com, kevin.tian@intel.com,
stefanha@redhat.com
Subject: Re: [PATCH V4 5/6] virtio: introduce a mdev based transport
Date: Mon, 21 Oct 2019 11:36:07 +0200 [thread overview]
Message-ID: <20191021113607.16b26d9d.cohuck@redhat.com> (raw)
In-Reply-To: <2bb5645b-5c46-9cae-0571-65c302f51cf2@redhat.com>
On Mon, 21 Oct 2019 13:59:23 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2019/10/18 下午10:20, Cornelia Huck wrote:
> > On Thu, 17 Oct 2019 18:48:35 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> This patch introduces a new mdev transport for virtio. This is used to
> >> use kernel virtio driver to drive the mediated device that is capable
> >> of populating virtqueue directly.
> >>
> >> A new virtio-mdev driver will be registered to the mdev bus, when a
> >> new virtio-mdev device is probed, it will register the device with
> >> mdev based config ops. This means it is a software transport between
> >> mdev driver and mdev device. The transport was implemented through
> >> device specific ops which is a part of mdev_parent_ops now.
> >>
> >> Signed-off-by: Jason Wang <jasowang@redhat.com>
> >> ---
> >> drivers/virtio/Kconfig | 7 +
> >> drivers/virtio/Makefile | 1 +
> >> drivers/virtio/virtio_mdev.c | 409 +++++++++++++++++++++++++++++++++++
> >> 3 files changed, 417 insertions(+)
> > (...)
> >
> >> +static int virtio_mdev_probe(struct device *dev)
> >> +{
> >> + struct mdev_device *mdev = mdev_from_dev(dev);
> >> + const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
> >> + struct virtio_mdev_device *vm_dev;
> >> + int rc;
> >> +
> >> + vm_dev = devm_kzalloc(dev, sizeof(*vm_dev), GFP_KERNEL);
> >> + if (!vm_dev)
> >> + return -ENOMEM;
> >> +
> >> + vm_dev->vdev.dev.parent = dev;
> >> + vm_dev->vdev.dev.release = virtio_mdev_release_dev;
> >> + vm_dev->vdev.config = &virtio_mdev_config_ops;
> >> + vm_dev->mdev = mdev;
> >> + INIT_LIST_HEAD(&vm_dev->virtqueues);
> >> + spin_lock_init(&vm_dev->lock);
> >> +
> >> + vm_dev->version = ops->get_mdev_features(mdev);
> >> + if (vm_dev->version != VIRTIO_MDEV_F_VERSION_1) {
> >> + dev_err(dev, "VIRTIO_MDEV_F_VERSION_1 is mandatory\n");
> >> + return -ENXIO;
> >> + }
> > Hm, so how is that mdev features interface supposed to work? If
> > VIRTIO_MDEV_F_VERSION_1 is a bit, I would expect this code to test for
> > its presence, and not for identity.
>
>
> This should be used by driver to detect the which sets of functions and
> their semantics that could be provided by the device. E.g when driver
> support both version 2 and version 1 but device only support version 1,
> driver can switch to use version 1. Btw, Is there a easy way for to test
> its presence or do you mean doing sanity testing on existence of the
> mandatory ops that provided by the device?
What I meant was something like:
features = ops->get_mdev_features(mdev);
if (features & VIRTIO_MDEV_F_VERSION_1)
vm_dev->version = 1;
else
//moan about missing support for version 1
Can there be class id specific extra features, or is this only for core
features? If the latter, maybe also do something like
supported_features = ORED_LIST_OF_FEATURES;
if (features & ~supported_features)
//moan about extra feature bits
>
>
> >
> > What will happen if we come up with a version 2? If this is backwards
> > compatible, will both version 2 and version 1 be set?
>
>
> Yes, I think so, and version 2 should be considered as some extensions
> of version 1. If it's completely, it should use a new class id.
Ok, that makes sense.
next prev parent reply other threads:[~2019-10-21 9:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 10:48 [PATCH V4 0/6] mdev based hardware virtio offloading support Jason Wang
2019-10-17 10:48 ` [PATCH V4 1/6] mdev: class id support Jason Wang
2019-10-20 23:25 ` Parav Pandit
2019-10-17 10:48 ` [PATCH V4 2/6] modpost: add support for mdev class id Jason Wang
2019-10-20 23:25 ` Parav Pandit
2019-10-17 10:48 ` [PATCH V4 3/6] mdev: introduce device specific ops Jason Wang
2019-10-17 15:07 ` Cornelia Huck
2019-10-17 17:53 ` Alex Williamson
2019-10-18 7:44 ` Cornelia Huck
2019-10-18 7:34 ` Jason Wang
2019-10-20 23:41 ` Parav Pandit
2019-10-21 6:02 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 4/6] mdev: introduce virtio device and its device ops Jason Wang
2019-10-17 17:53 ` Alex Williamson
2019-10-18 7:35 ` Jason Wang
2019-10-18 9:46 ` Cornelia Huck
2019-10-18 10:55 ` Jason Wang
2019-10-18 13:30 ` Cornelia Huck
2019-10-21 5:36 ` Jason Wang
2019-10-18 9:46 ` Tiwei Bie
2019-10-18 10:57 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 5/6] virtio: introduce a mdev based transport Jason Wang
2019-10-18 14:20 ` Cornelia Huck
2019-10-21 5:59 ` Jason Wang
2019-10-21 9:36 ` Cornelia Huck [this message]
2019-10-21 10:13 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
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=20191021113607.16b26d9d.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=airlied@linux.ie \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=christophe.de.dinechin@gmail.com \
--cc=cunming.liang@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=eperezma@redhat.com \
--cc=farman@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=haotian.wang@sifive.com \
--cc=heiko.carstens@de.ibm.com \
--cc=idos@mellanox.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jasowang@redhat.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=lingshan.zhu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=parav@mellanox.com \
--cc=pasic@linux.ibm.com \
--cc=rob.miller@broadcom.com \
--cc=rodrigo.vivi@intel.com \
--cc=sebott@linux.ibm.com \
--cc=stefanha@redhat.com \
--cc=tiwei.bie@intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xiao.w.wang@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@intel.com \
--cc=zhihong.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).