All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Boeuf, Sebastien" <sebastien.boeuf@intel.com>
Cc: "eperezma@redhat.com" <eperezma@redhat.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 2/4] vhost-vdpa: Introduce RESUME backend feature bit
Date: Fri, 14 Oct 2022 05:42:53 -0400	[thread overview]
Message-ID: <20221014054201-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <fb0d70a095a26a8f8adf4d7659787596d2763ef6.camel@intel.com>

On Fri, Oct 14, 2022 at 09:40:46AM +0000, Boeuf, Sebastien wrote:
> On Fri, 2022-10-14 at 05:37 -0400, Michael S. Tsirkin wrote:
> > 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@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@intel.com>
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > From: Sebastien Boeuf <sebastien.boeuf@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@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.
> 
> So solution number 2? I keep this code and add some logic to the
> GET_BACKEND_FEATURES ioctl so that it wouldn't return the RESUME bit if
> the backend isn't capable of being suspended?

No, what I mean is that caller of SET_BACKEND_FEATURES should not
set RESUME if SUSPEND is not set, and if it does I see no reason to
intervene.


> > 
> 
> ---------------------------------------------------------------------
> 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.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2022-10-14  9:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1665674878.git.sebastien.boeuf@intel.com>
     [not found] ` <72bdc9ae91ca4ed8a2c9ea2aab53f8e04d4512f6.1665674878.git.sebastien.boeuf@intel.com>
2022-10-14  5:58   ` [PATCH 2/4] vhost-vdpa: Introduce RESUME backend feature bit Jason Wang
2022-10-14  6:05     ` Michael S. Tsirkin
2022-10-14  6:09       ` Jason Wang
2022-10-14  6:11         ` Michael S. Tsirkin
     [not found]           ` <14fc89d250788d7bdbd6b522197efc2c19ff6db8.camel@intel.com>
2022-10-14  9:37             ` Michael S. Tsirkin
     [not found]               ` <fb0d70a095a26a8f8adf4d7659787596d2763ef6.camel@intel.com>
2022-10-14  9:42                 ` Michael S. Tsirkin [this message]
     [not found]                   ` <129e9d73551e53c3704a1dcdb3626c0e712eed99.camel@intel.com>
2022-10-14 14:19                     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221014054201-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=sebastien.boeuf@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.