linux-kernel - Re: [PATCH vhost v4 02/15] vdpa: Add VHOST_BACKEND_F_CHANGEABLE_VQ_ADDR_IN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <70adc734331c1289dceb3bcdc991f3da7e4db2f0.camel@nvidia.com>
Date: Thu, 21 Dec 2023 11:52:33 +0000
From: Dragos Tatulea <dtatulea@...dia.com>
To: "jasowang@...hat.com" <jasowang@...hat.com>, "eperezma@...hat.com"
	<eperezma@...hat.com>
CC: "xuanzhuo@...ux.alibaba.com" <xuanzhuo@...ux.alibaba.com>, Parav Pandit
	<parav@...dia.com>, "virtualization@...ts.linux-foundation.org"
	<virtualization@...ts.linux-foundation.org>, Gal Pressman <gal@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"si-wei.liu@...cle.com" <si-wei.liu@...cle.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "mst@...hat.com" <mst@...hat.com>, Saeed Mahameed
	<saeedm@...dia.com>, "leon@...nel.org" <leon@...nel.org>
Subject: Re: [PATCH vhost v4 02/15] vdpa: Add
 VHOST_BACKEND_F_CHANGEABLE_VQ_ADDR_IN_SUSPEND flag

On Thu, 2023-12-21 at 08:46 +0100, Eugenio Perez Martin wrote:
> On Thu, Dec 21, 2023 at 3:03 AM Jason Wang <jasowang@...hat.com> wrote:
> > 
> > On Wed, Dec 20, 2023 at 9:32 PM Eugenio Perez Martin
> > <eperezma@...hat.com> wrote:
> > > 
> > > On Wed, Dec 20, 2023 at 5:06 AM Jason Wang <jasowang@...hat.com> wrote:
> > > > 
> > > > On Wed, Dec 20, 2023 at 11:46 AM Jason Wang <jasowang@...hat.com> wrote:
> > > > > 
> > > > > On Wed, Dec 20, 2023 at 2:09 AM Dragos Tatulea <dtatulea@...dia.com> wrote:
> > > > > > 
> > > > > > The virtio spec doesn't allow changing virtqueue addresses after
> > > > > > DRIVER_OK. Some devices do support this operation when the device is
> > > > > > suspended. The VHOST_BACKEND_F_CHANGEABLE_VQ_ADDR_IN_SUSPEND flag
> > > > > > advertises this support as a backend features.
> > > > > 
> > > > > There's an ongoing effort in virtio spec to introduce the suspend state.
> > > > > 
> > > > > So I wonder if it's better to just allow such behaviour?
> > > > 
> > > > Actually I mean, allow drivers to modify the parameters during suspend
> > > > without a new feature.
> > > > 
> > > 
> > > That would be ideal, but how do userland checks if it can suspend +
> > > change properties + resume?
> > 
> > As discussed, it looks to me the only device that supports suspend is
> > simulator and it supports change properties.
> > 
> > E.g:
> > 
> > static int vdpasim_set_vq_address(struct vdpa_device *vdpa, u16 idx,
> >                                   u64 desc_area, u64 driver_area,
> >                                   u64 device_area)
> > {
> >         struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
> >         struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx];
> > 
> >         vq->desc_addr = desc_area;
> >         vq->driver_addr = driver_area;
> >         vq->device_addr = device_area;
> > 
> >         return 0;
> > }
> > 
> 
> So in the current kernel master it is valid to set a different vq
> address while the device is suspended in vdpa_sim. But it is not valid
> in mlx5, as the FW will not be updated in resume (Dragos, please
> correct me if I'm wrong). Both of them return success.
> 
In the current state, there is no resume. HW Virtqueues will just get re-created
with the new address. 

> How can we know in the destination QEMU if it is valid to suspend &
> set address? Should we handle this as a bugfix and backport the
> change?
> 
> > > 
> > > The only way that comes to my mind is to make sure all parents return
> > > error if userland tries to do it, and then fallback in userland.
> > 
> > Yes.
> > 
> > > I'm
> > > ok with that, but I'm not sure if the current master & previous kernel
> > > has a coherent behavior. Do they return error? Or return success
> > > without changing address / vq state?
> > 
> > We probably don't need to worry too much here, as e.g set_vq_address
> > could fail even without suspend (just at uAPI level).
> > 
> 
> I don't get this, sorry. I rephrased my point with an example earlier
> in the mail.
>