On Mon, Jun 9, 2025 at 2:11 PM Eugenio Perez Martin [off-list ref] wrote:

On Mon, Jun 9, 2025 at 3:50 AM Jason Wang [off-list ref] wrote:

quoted

On Mon, Jun 9, 2025 at 9:41 AM Jason Wang [off-list ref] wrote:

quoted

On Fri, Jun 6, 2025 at 7:50 PM Eugenio Pérez [off-list ref] wrote:

quoted

This allows to define all functions checking the API version set by the
userland device.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>

It might be worth clarifying how it works.

For example,

1) would VDUSE behave differently or if it's just some new ioctls

I'd like to test more in-depth, but a device can just bump the version
ID and then implement the replies to the vduse messages. No need to
implement new ioctls. If the VDUSE device sets 0 in either number of
ASID or vq groups, the kernel assumes 1.

Right, this is the way we use now and I think maybe we can document
this somewhere.

But you have a very good point here, I think it is wise to evaluate
the shortcut of these messages in the VDUSE kernel module. If a VDUSE
device only has one vq group and one ASID, it can always return group
0 and asid 0 for everything, and fail every try to ser asid != 0.

Yes, and vhost-vDPA needs to guard against the misconfiguration.

This
way, the update is transparent for the VDUSE device, and future
devices do not need to implement the reply of these. What do you
think?

This should work.

quoted

quoted

2) If VDUSE behave differently, do we need a ioctl to set the API
version for backward compatibility?

Speak too fast, there's a VDUSE_SET_API_VERSION actually.

I think we need to think if it complicates the migration compatibility or not.

Do you mean migration as "increase the VDUSE version number", not "VM
live migration from vduse version 0 to vduse version 1", isn't it? The
second should not have any problem but I haven't tested it.

I mean if we bump the version, we can't migrate from version 1 to
version 0. Or we can offload this to the management (do we need to
extend the vdpa tool for this)?

Thanks