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
| ||
|
Message-ID: <CACGkMEv8bQwahTB8x7JjYB3hTT76_QYQEMiHm7jN_gQXPz4Wsw@mail.gmail.com> Date: Fri, 22 Dec 2023 10:50:23 +0800 From: Jason Wang <jasowang@...hat.com> To: Eugenio Perez Martin <eperezma@...hat.com> Cc: Dragos Tatulea <dtatulea@...dia.com>, "Michael S . Tsirkin" <mst@...hat.com>, Si-Wei Liu <si-wei.liu@...cle.com>, Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>, virtualization@...ts.linux-foundation.org, Gal Pressman <gal@...dia.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, Parav Pandit <parav@...dia.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com> Subject: Re: [PATCH vhost v4 02/15] vdpa: Add VHOST_BACKEND_F_CHANGEABLE_VQ_ADDR_IN_SUSPEND flag On Thu, Dec 21, 2023 at 3:47 PM Eugenio Perez Martin <eperezma@...hat.com> 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. > > 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? Good point. We probably need to do backport, this seems to be the easiest way. Theoretically, userspace may assume this behavior (though I don't think there would be a user that depends on the simulator). > > > > > > > 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. I mean currently, VHOST_SET_VRING_ADDR can fail. So userspace should not assume it will always succeed. Thanks >
Powered by blists - more mailing lists