On Mon, Apr 12, 2021 at 02:35:07PM +0800, Jason Wang wrote:
在 2021/4/10 上午12:04, Michael S. Tsirkin 写道:
On Fri, Apr 09, 2021 at 12:47:55PM +0800, Jason Wang wrote:
在 2021/4/8 下午11:59, Michael S. Tsirkin 写道:My point is this neither fixes or prevents this.
On Thu, Apr 08, 2021 at 04:26:48PM +0800, Jason Wang wrote:Yes, but it's not something that is introduced in this commit. The legacy
This patch mandates 1.0 for vDPA devices. The goal is to have theHmm. If we do this, don't we still have a problem with
semantic of normative statement in the virtio spec and eliminate the
burden of transitional device for both vDPA bus and vDPA parent.
uAPI seems fine since all the vDPA parent mandates
VIRTIO_F_ACCESS_PLATFORM which implies 1.0 devices.
For legacy guests, it can still work since Qemu will mediate when
necessary (e.g doing the endian conversion).
Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx>
legacy drivers which don't ack 1.0?
driver never work ...
So my suggestion is to finally add ioctls along the lines
of PROTOCOL_FEATURES of vhost-user.
Then that one can have bits for legacy le, legacy be and modern.
BTW I looked at vhost-user and it does not look like that
has a solution for this problem either, right?
Right.
I frankly think we'll need PROTOCOL_FEATURES anyway, it's too useful ...Note 1.0 affects ring endianness which is not mediated in QEMURight, I plan to send patches to do mediation in the Qemu to unbreak legacy
so QEMU can't pretend to device guest is 1.0.
drivers.
Thanks
so why not teach drivers about it and be done with it? You can't emulate
legacy on modern in a cross endian situation because of vring
endian-ness ...
So the problem still. This can only work when the hardware can support
legacy vring endian-ness.
Consider:
1) the leagcy driver support is non-normative in the spec
2) support a transitional device in the kenrel may requires the hardware
support and a burden of kernel codes
I'd rather simply drop the legacy driver support
My point is this patch does not drop legacy support. It merely mandates
modern support.
to have a simple and easyI'd like to avoid shadow virtqueue hacks if at all possible.
abstarction in the kenrel. For legacy driver in the guest, hypervisor is in
charge of the mediation:
1) config space access endian conversion
2) using shadow virtqueue to change the endian in the vring
Thanks
Last I checked performance wasn't much better than just emulating
virtio in software.
---
include/linux/vdpa.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 0fefeb976877..cfde4ec999b4 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -6,6 +6,7 @@
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/vhost_iotlb.h>
+#include <uapi/linux/virtio_config.h>
/**
* vDPA callback definition.
@@ -317,6 +318,11 @@ static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)
{
const struct vdpa_config_ops *ops = vdev->config;
+ /* Mandating 1.0 to have semantics of normative statements in
+ * the spec. */
+ if (!(features & BIT_ULL(VIRTIO_F_VERSION_1)))
+ return -EINVAL;
+
vdev->features_valid = true;
return ops->set_features(vdev, features);
}
--
2.25.1