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$(echo .)com \
--cc=airlied@linux$(echo .)ie \
--cc=akrowiak@linux$(echo .)ibm.com \
--cc=alex.williamson@redhat$(echo .)com \
--cc=borntraeger@de$(echo .)ibm.com \
--cc=christophe.de.dinechin@gmail$(echo .)com \
--cc=cunming.liang@intel$(echo .)com \
--cc=daniel@ffwll$(echo .)ch \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=eperezma@redhat$(echo .)com \
--cc=farman@linux$(echo .)ibm.com \
--cc=freude@linux$(echo .)ibm.com \
--cc=gor@linux$(echo .)ibm.com \
--cc=haotian.wang@sifive$(echo .)com \
--cc=heiko.carstens@de$(echo .)ibm.com \
--cc=idos@mellanox$(echo .)com \
--cc=intel-gfx@lists$(echo .)freedesktop.org \
--cc=intel-gvt-dev@lists$(echo .)freedesktop.org \
--cc=jani.nikula@linux$(echo .)intel.com \
--cc=jasowang@redhat$(echo .)com \
--cc=joonas.lahtinen@linux$(echo .)intel.com \
--cc=kevin.tian@intel$(echo .)com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=kwankhede@nvidia$(echo .)com \
--cc=lingshan.zhu@intel$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=lulu@redhat$(echo .)com \
--cc=maxime.coquelin@redhat$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oberpar@linux$(echo .)ibm.com \
--cc=parav@mellanox$(echo .)com \
--cc=pasic@linux$(echo .)ibm.com \
--cc=rob.miller@broadcom$(echo .)com \
--cc=rodrigo.vivi@intel$(echo .)com \
--cc=sebott@linux$(echo .)ibm.com \
--cc=stefanha@redhat$(echo .)com \
--cc=tiwei.bie@intel$(echo .)com \
--cc=virtualization@lists$(echo .)linux-foundation.org \
--cc=xiao.w.wang@intel$(echo .)com \
--cc=zhenyuw@linux$(echo .)intel.com \
--cc=zhi.a.wang@intel$(echo .)com \
--cc=zhihong.wang@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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