Re: vdpa legacy guest support (was Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero)

On Fri, Dec 17, 2021 at 10:01 AM Michael S. Tsirkin [off-list ref] wrote:

On Fri, Dec 17, 2021 at 09:57:38AM +0800, Jason Wang wrote:

quoted

On Fri, Dec 17, 2021 at 6:32 AM Si-Wei Liu [off-list ref] wrote:

quoted

On 12/15/2021 6:53 PM, Jason Wang wrote:

quoted

On Thu, Dec 16, 2021 at 10:02 AM Si-Wei Liu [off-list ref] wrote:

quoted

On 12/15/2021 1:33 PM, Michael S. Tsirkin wrote:

quoted

On Wed, Dec 15, 2021 at 12:52:20PM -0800, Si-Wei Liu wrote:

quoted

On 12/14/2021 6:06 PM, Jason Wang wrote:

quoted

On Wed, Dec 15, 2021 at 9:05 AM Si-Wei Liu [off-list ref] wrote:

quoted

On 12/13/2021 9:06 PM, Michael S. Tsirkin wrote:

quoted

On Mon, Dec 13, 2021 at 05:59:45PM -0800, Si-Wei Liu wrote:

quoted

On 12/12/2021 1:26 AM, Michael S. Tsirkin wrote:

quoted

On Fri, Dec 10, 2021 at 05:44:15PM -0800, Si-Wei Liu wrote:

quoted

Sorry for reviving this ancient thread. I was kinda lost for the conclusion
it ended up with. I have the following questions,

1. legacy guest support: from the past conversations it doesn't seem the
support will be completely dropped from the table, is my understanding
correct? Actually we're interested in supporting virtio v0.95 guest for x86,
which is backed by the spec at
https://urldefense.com/v3/__https://ozlabs.org/*rusty/virtio-spec/virtio-0.9.5.pdf__;fg!!ACWV5N9M2RV99hQ!dTKmzJwwRsFM7BtSuTDu1cNly5n4XCotH0WYmidzGqHSXt40i7ZU43UcNg7GYxZg$ . Though I'm not sure
if there's request/need to support wilder legacy virtio versions earlier
beyond.

I personally feel it's less work to add in kernel than try to
work around it in userspace. Jason feels differently.
Maybe post the patches and this will prove to Jason it's not
too terrible?

I suppose if the vdpa vendor does support 0.95 in the datapath and ring
layout level and is limited to x86 only, there should be easy way out.

Note a subtle difference: what matters is that guest, not host is x86.
Matters for emulators which might reorder memory accesses.
I guess this enforcement belongs in QEMU then?

Right, I mean to get started, the initial guest driver support and the
corresponding QEMU support for transitional vdpa backend can be limited
to x86 guest/host only. Since the config space is emulated in QEMU, I
suppose it's not hard to enforce in QEMU.

It's more than just config space, most devices have headers before the buffer.

The ordering in datapath (data VQs) would have to rely on vendor's support.
Since ORDER_PLATFORM is pretty new (v1.1), I guess vdpa h/w vendor nowadays
can/should well support the case when ORDER_PLATFORM is not acked by the
driver (actually this feature is filtered out by the QEMU vhost-vdpa driver
today), even with v1.0 spec conforming and modern only vDPA device. The
control VQ is implemented in software in the kernel, which can be easily
accommodated/fixed when needed.

quoted

quoted

QEMU can drive GET_LEGACY,
GET_ENDIAN et al ioctls in advance to get the capability from the
individual vendor driver. For that, we need another negotiation protocol
similar to vhost_user's protocol_features between the vdpa kernel and
QEMU, way before the guest driver is ever probed and its feature
negotiation kicks in. Not sure we need a GET_MEMORY_ORDER ioctl call
from the device, but we can assume weak ordering for legacy at this
point (x86 only)?

I'm lost here, we have get_features() so:

I assume here you refer to get_device_features() that Eli just changed the
name.

quoted

1) VERSION_1 means the device uses LE if provided, otherwise natvie
2) ORDER_PLATFORM means device requires platform ordering

Any reason for having a new API for this?

Are you going to enforce all vDPA hardware vendors to support the
transitional model for legacy guest?

Do we really have other choices?

I suspect the legacy device is never implemented by any vendor:

1) no virtio way to detect host endian

This is even true for transitional device that is conforming to the
spec, right?

For hardware, yes.

quoted

The transport specific way to detect host endian is still
being discussed and the spec revision is not finalized yet so far as I
see. Why this suddenly becomes a requirement/blocker for h/w vendors to
implement the transitional model?

It's not a sudden blocker, the problem has existed since day 0 if I
was not wrong. That's why the problem looks a little bit complicated
and why it would be much simpler if we stick to modern devices.

quoted

Even if the spec is out, this is
pretty new and I suspect not all vendor would follow right away. I hope
the software framework can be tolerant with h/w vendors not supporting
host endianess (BE specifically) or not detecting it if they would like
to support a transitional device for legacy.

Well, if we know we don't want to support the BE host it would be fine.

I think you guys mean guest not host here. Same for memory ordering etc.
What matters is whether guest has barriers etc.

Yes.

Thanks