On Wed, Dec 13, 2023 at 7:23 PM Maxime Coquelin
[off-list ref] wrote:

Hi Jason,

On 12/13/23 05:52, Jason Wang wrote:

quoted

On Tue, Dec 12, 2023 at 9:17 PM Maxime Coquelin
[off-list ref] wrote:

quoted

Virtio-net driver control queue implementation is not safe
when used with VDUSE. If the VDUSE application does not
reply to control queue messages, it currently ends up
hanging the kernel thread sending this command.

Some work is on-going to make the control queue
implementation robust with VDUSE. Until it is completed,
let's disable control virtqueue and features that depend on
it.

Signed-off-by: Maxime Coquelin <redacted>

I wonder if it's better to fail instead of a mask as a start.

I think it is better to use a mask and not fail, so that we can in the
future use a recent VDUSE application with an older kernel.

It may confuse the userspace unless userspace can do post check after
CREATE_DEV.

And for blk we fail when WCE is set in feature_is_valid():

static bool features_is_valid(u64 features)
{
        if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
                return false;

        /* Now we only support read-only configuration space */
        if (features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))
                return false;

        return true;
}

Thanks

Why would it be better to fail than negotiating?

Thanks,
Maxime