Michael S. Tsirkin
2022-Oct-14 09:37 UTC
[PATCH 2/4] vhost-vdpa: Introduce RESUME backend feature bit
On Fri, Oct 14, 2022 at 08:07:08AM +0000, Boeuf, Sebastien wrote:> On Fri, 2022-10-14 at 02:11 -0400, Michael S. Tsirkin wrote: > > On Fri, Oct 14, 2022 at 02:09:02PM +0800, Jason Wang wrote: > > > On Fri, Oct 14, 2022 at 2:05 PM Michael S. Tsirkin <mst at redhat.com> > > > wrote: > > > > > > > > On Fri, Oct 14, 2022 at 01:58:38PM +0800, Jason Wang wrote: > > > > > On Thu, Oct 13, 2022 at 11:35 PM <sebastien.boeuf at intel.com> > > > > > wrote: > > > > > > > > > > > > From: Sebastien Boeuf <sebastien.boeuf at intel.com> > > > > > > > > > > > > Userspace knows if the device can be resumed or not by > > > > > > checking this > > > > > > feature bit. > > > > > > > > > > > > It's only exposed if the vdpa driver backend implements the > > > > > > resume() > > > > > > operation callback. Userspace trying to negotiate this > > > > > > feature when it > > > > > > hasn't been exposed will result in an error. > > > > > > > > > > > > Signed-off-by: Sebastien Boeuf <sebastien.boeuf at intel.com> > > > > > > --- > > > > > > ?drivers/vhost/vdpa.c???????????? | 19 ++++++++++++++++++- > > > > > > ?include/uapi/linux/vhost_types.h |? 2 ++ > > > > > > ?2 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > > > > > > index 166044642fd5..161727e1a9a5 100644 > > > > > > --- a/drivers/vhost/vdpa.c > > > > > > +++ b/drivers/vhost/vdpa.c > > > > > > @@ -355,6 +355,14 @@ static bool vhost_vdpa_can_suspend(const > > > > > > struct vhost_vdpa *v) > > > > > > ??????? return ops->suspend; > > > > > > ?} > > > > > > > > > > > > +static bool vhost_vdpa_can_resume(const struct vhost_vdpa > > > > > > *v) > > > > > > +{ > > > > > > +?????? struct vdpa_device *vdpa = v->vdpa; > > > > > > +?????? const struct vdpa_config_ops *ops = vdpa->config; > > > > > > + > > > > > > +?????? return ops->resume; > > > > > > +} > > > > > > + > > > > > > ?static long vhost_vdpa_get_features(struct vhost_vdpa *v, > > > > > > u64 __user *featurep) > > > > > > ?{ > > > > > > ??????? struct vdpa_device *vdpa = v->vdpa; > > > > > > @@ -602,11 +610,18 @@ static long > > > > > > vhost_vdpa_unlocked_ioctl(struct file *filep, > > > > > > ??????????????? if (copy_from_user(&features, featurep, > > > > > > sizeof(features))) > > > > > > ??????????????????????? return -EFAULT; > > > > > > ??????????????? if (features & ~(VHOST_VDPA_BACKEND_FEATURES > > > > > > | > > > > > > -??????????????????????????????? > > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND))) > > > > > > +??????????????????????????????? > > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND) | > > > > > > +??????????????????????????????? > > > > > > BIT_ULL(VHOST_BACKEND_F_RESUME))) > > > > > > ??????????????????????? return -EOPNOTSUPP; > > > > > > ??????????????? if ((features & > > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND)) && > > > > > > ???????????????????? !vhost_vdpa_can_suspend(v)) > > > > > > ??????????????????????? return -EOPNOTSUPP; > > > > > > +?????????????? if ((features & > > > > > > BIT_ULL(VHOST_BACKEND_F_RESUME)) && > > > > > > +??????????????????? !vhost_vdpa_can_resume(v)) > > > > > > +?????????????????????? return -EOPNOTSUPP; > > > > > > +?????????????? if (!(features & > > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND)) && > > > > > > +??????????????????? (features & > > > > > > BIT_ULL(VHOST_BACKEND_F_RESUME))) > > > > > > +?????????????????????? return -EINVAL; > > > > > > > > > > Is it better to do the check during the probe? It should be a > > > > > bug that > > > > > we're having a parent that can only do resume but not suspend. > > > > > > > > > > Thanks > > > > > > > > well we separated them in the spec ... > > > > suspend could have other uses, I won't say it's an invalid > > > > config. > > > > > > For suspend only, yes. But we should fail the probe with a resume > > > only, this is somehow the above code wants to check. Or anything I > > > missed? > > > > > > Thanks > > > > I am not sure but I would say failing probe is a drastic measure. > > if we have no use for a given combination of features let us clear > > the > > feature bit in validation. > > The current patch only returns an error to the user who might be trying > to set the RESUME feature bit without the SUSPEND one. But I agree if > we go down this road, it might be better to also return an error during > the probe of the backend driver if it provides only the resume > operation. > > The alternative is to never return the RESUME feature bit as available > (through GET_BACKEND_FEATURES) if the device is not capable of being > suspended. This way the vdpa framework would never advertise a RESUME > feature bit without the SUSPEND one, and the only error that would have > to be handled should be on the SET_BACKEND_FEATURES (which is what this > patch does). > > Please let me know which approach sounds the most appropriate. > > Thanks, > Sebastien > > > > > > > > > > > > > ??????????????? vhost_set_backend_features(&v->vdev, > > > > > > features); > > > > > > ??????????????? return 0; > > > > > > ??????? } > > > > > > @@ -658,6 +673,8 @@ static long > > > > > > vhost_vdpa_unlocked_ioctl(struct file *filep, > > > > > > ??????????????? features = VHOST_VDPA_BACKEND_FEATURES; > > > > > > ??????????????? if (vhost_vdpa_can_suspend(v)) > > > > > > ??????????????????????? features |> > > > > > BIT_ULL(VHOST_BACKEND_F_SUSPEND); > > > > > > +?????????????? if (vhost_vdpa_can_resume(v)) > > > > > > +?????????????????????? features |> > > > > > BIT_ULL(VHOST_BACKEND_F_RESUME); > > > > > > ??????????????? if (copy_to_user(featurep, &features, > > > > > > sizeof(features))) > > > > > > ??????????????????????? r = -EFAULT; > > > > > > ??????????????? break; > > > > > > diff --git a/include/uapi/linux/vhost_types.h > > > > > > b/include/uapi/linux/vhost_types.h > > > > > > index 53601ce2c20a..c5690a8992d8 100644 > > > > > > --- a/include/uapi/linux/vhost_types.h > > > > > > +++ b/include/uapi/linux/vhost_types.h > > > > > > @@ -163,5 +163,7 @@ struct vhost_vdpa_iova_range { > > > > > > ?#define VHOST_BACKEND_F_IOTLB_ASID? 0x3 > > > > > > ?/* Device can be suspended */ > > > > > > ?#define VHOST_BACKEND_F_SUSPEND? 0x4 > > > > > > +/* Device can be resumed */ > > > > > > +#define VHOST_BACKEND_F_RESUME? 0x5 > > > > > > > > > > > > ?#endif > > > > > > -- > > > > > > 2.34.1 > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > -------- > > > > > > Intel Corporation SAS (French simplified joint stock company) > > > > > > Registered headquarters: "Les Montalets"- 2, rue de Paris, > > > > > > 92196 Meudon Cedex, France > > > > > > Registration Number:? 302 456 199 R.C.S. NANTERRE > > > > > > Capital: 5 208 026.16 Euros > > > > > > > > > > > > This e-mail and any attachments may contain confidential > > > > > > material for > > > > > > the sole use of the intended recipient(s). Any review or > > > > > > distribution > > > > > > by others is strictly prohibited. If you are not the intended > > > > > > recipient, please contact the sender and delete all copies. > > > > > > > > > > > > > > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 5 208 026.16 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies.I really feel it's up to the driver. -- MST