On Wed, Dec 20, 2023 at 9:32 PM Eugenio Perez Martin
<eperezma@xxxxxxxxxx> wrote:
>
> On Wed, Dec 20, 2023 at 5:06 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> >
> > On Wed, Dec 20, 2023 at 11:46 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Dec 20, 2023 at 2:09 AM Dragos Tatulea <dtatulea@xxxxxxxxxx> 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;
}
>
> 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).
Thanks
>
