Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 2 Mar 2021 04:47:07 -0500
From:   "Michael S. Tsirkin" <mst@redhat.com>
To:     Jason Wang <jasowang@redhat.com>
Cc:     Si-Wei Liu <si-wei.liu@oracle.com>, elic@nvidia.com,
        linux-kernel@vger.kernel.org,
        virtualization@lists.linux-foundation.org, netdev@vger.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero
Message-ID: <20210302043419-mutt-send-email-mst@kernel.org>
References: <605e7d2d-4f27-9688-17a8-d57191752ee7@redhat.com>
 <20210222023040-mutt-send-email-mst@kernel.org>
 <22fe5923-635b-59f0-7643-2fd5876937c2@oracle.com>
 <fae0bae7-e4cd-a3aa-57fe-d707df99b634@redhat.com>
 <20210223082536-mutt-send-email-mst@kernel.org>
 <3ff5fd23-1db0-2f95-4cf9-711ef403fb62@oracle.com>
 <20210224000057-mutt-send-email-mst@kernel.org>
 <52836a63-4e00-ff58-50fb-9f450ce968d7@oracle.com>
 <20210228163031-mutt-send-email-mst@kernel.org>
 <2cb51a6d-afa0-7cd1-d6f2-6b153186eaca@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2cb51a6d-afa0-7cd1-d6f2-6b153186eaca@redhat.com>
Precedence: bulk

On Mon, Mar 01, 2021 at 11:56:50AM +0800, Jason Wang wrote:
> 
> On 2021/3/1 5:34 上午, Michael S. Tsirkin wrote:
> > On Wed, Feb 24, 2021 at 10:24:41AM -0800, Si-Wei Liu wrote:
> > > > Detecting it isn't enough though, we will need a new ioctl to notify
> > > > the kernel that it's a legacy guest. Ugh :(
> > > Well, although I think adding an ioctl is doable, may I know what the use
> > > case there will be for kernel to leverage such info directly? Is there a
> > > case QEMU can't do with dedicate ioctls later if there's indeed
> > > differentiation (legacy v.s. modern) needed?
> > BTW a good API could be
> > 
> > #define VHOST_SET_ENDIAN _IOW(VHOST_VIRTIO, ?, int)
> > #define VHOST_GET_ENDIAN _IOW(VHOST_VIRTIO, ?, int)
> > 
> > we did it per vring but maybe that was a mistake ...
> 
> 
> Actually, I wonder whether it's good time to just not support legacy driver
> for vDPA. Consider:
> 
> 1) It's definition is no-normative
> 2) A lot of budren of codes
> 
> So qemu can still present the legacy device since the config space or other
> stuffs that is presented by vhost-vDPA is not expected to be accessed by
> guest directly. Qemu can do the endian conversion when necessary in this
> case?
> 
> Thanks
> 

Overall I would be fine with this approach but we need to avoid breaking
working userspace, qemu releases with vdpa support are out there and
seem to work for people. Any changes need to take that into account
and document compatibility concerns. I note that any hardware
implementation is already broken for legacy except on platforms with
strong ordering which might be helpful in reducing the scope.


-- 
MST