From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
bhelgaas@google.com, saeedm@nvidia.com,
linux-pci@vger.kernel.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, kuba@kernel.org, leonro@nvidia.com,
kwankhede@nvidia.com, mgurtovoy@nvidia.com, maorg@nvidia.com
Subject: Re: [PATCH V1 mlx5-next 11/13] vfio/mlx5: Implement vfio_pci driver for mlx5 devices
Date: Fri, 15 Oct 2021 17:16:54 -0300 [thread overview]
Message-ID: <20211015201654.GH2744544@nvidia.com> (raw)
In-Reply-To: <20211015141201.617049e9.alex.williamson@redhat.com>
On Fri, Oct 15, 2021 at 02:12:01PM -0600, Alex Williamson wrote:
> On Fri, 15 Oct 2021 16:59:37 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> > On Fri, Oct 15, 2021 at 01:48:20PM -0600, Alex Williamson wrote:
> > > > +static int mlx5vf_pci_set_device_state(struct mlx5vf_pci_core_device *mvdev,
> > > > + u32 state)
> > > > +{
> > > > + struct mlx5vf_pci_migration_info *vmig = &mvdev->vmig;
> > > > + u32 old_state = vmig->vfio_dev_state;
> > > > + int ret = 0;
> > > > +
> > > > + if (vfio_is_state_invalid(state) || vfio_is_state_invalid(old_state))
> > > > + return -EINVAL;
> > >
> > > if (!VFIO_DEVICE_STATE_VALID(old_state) || !VFIO_DEVICE_STATE_VALID(state))
> >
> > AFAICT this macro doesn't do what is needed, eg
> >
> > VFIO_DEVICE_STATE_VALID(0xF000) == true
> >
> > What Yishai implemented is at least functionally correct - states this
> > driver does not support are rejected.
>
>
> if (!VFIO_DEVICE_STATE_VALID(old_state) || !VFIO_DEVICE_STATE_VALID(state)) || (state & ~VFIO_DEVICE_STATE_MASK))
>
> old_state is controlled by the driver and can never have random bits
> set, user state should be sanitized to prevent setting undefined bits.
In that instance let's just write
old_state != VFIO_DEVICE_STATE_ERROR
?
I'm happy to see some device specific mask selecting the bits it
supports.
> > > > + /* Running switches off */
> > > > + if ((old_state & VFIO_DEVICE_STATE_RUNNING) !=
> > > > + (state & VFIO_DEVICE_STATE_RUNNING) &&
> > >
> > > ((old_state ^ state) & VFIO_DEVICE_STATE_RUNNING) ?
> >
> > It is not functionally the same, xor only tells if the bit changed, it
> > doesn't tell what the current value is, and this needs to know that it
> > changed to 1
>
> That's why I inserted my comment after the "it changed" test and not
> after the "and the old old value was..." test below.
Oh, I see, it was not clear to me
Thanks,
Jason
next prev parent reply other threads:[~2021-10-15 20:16 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 9:46 [PATCH V1 mlx5-next 00/13] Add mlx5 live migration driver Yishai Hadas
2021-10-13 9:46 ` [PATCH V1 mlx5-next 01/13] PCI/IOV: Provide internal VF index Yishai Hadas
2021-10-13 18:14 ` Bjorn Helgaas
2021-10-14 9:08 ` Yishai Hadas
2021-10-13 9:46 ` [PATCH V1 mlx5-next 02/13] net/mlx5: Reuse exported virtfn index function call Yishai Hadas
2021-10-13 9:46 ` [PATCH V1 mlx5-next 03/13] net/mlx5: Disable SRIOV before PF removal Yishai Hadas
2021-10-13 9:46 ` [PATCH V1 mlx5-next 04/13] PCI/IOV: Allow SRIOV VF drivers to reach the drvdata of a PF Yishai Hadas
2021-10-13 18:27 ` Bjorn Helgaas
2021-10-14 22:11 ` Alex Williamson
2021-10-17 13:43 ` Yishai Hadas
2021-10-13 9:46 ` [PATCH V1 mlx5-next 05/13] net/mlx5: Expose APIs to get/put the mlx5 core device Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 06/13] vdpa/mlx5: Use mlx5_vf_get_core_dev() to get PF device Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 07/13] vfio: Add 'invalid' state definitions Yishai Hadas
2021-10-15 16:38 ` Alex Williamson
2021-10-17 14:07 ` Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 08/13] vfio/pci_core: Make the region->release() function optional Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 09/13] net/mlx5: Introduce migration bits and structures Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 10/13] vfio/mlx5: Expose migration commands over mlx5 device Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 11/13] vfio/mlx5: Implement vfio_pci driver for mlx5 devices Yishai Hadas
2021-10-15 19:48 ` Alex Williamson
2021-10-15 19:59 ` Jason Gunthorpe
2021-10-15 20:12 ` Alex Williamson
2021-10-15 20:16 ` Jason Gunthorpe [this message]
2021-10-15 20:59 ` Alex Williamson
2021-10-17 14:03 ` Yishai Hadas
2021-10-18 11:51 ` Jason Gunthorpe
2021-10-18 13:26 ` Yishai Hadas
2021-10-18 13:42 ` Alex Williamson
2021-10-18 13:46 ` Yishai Hadas
2021-10-19 9:59 ` Shameerali Kolothum Thodi
2021-10-19 10:30 ` Yishai Hadas
2021-10-19 11:26 ` Shameerali Kolothum Thodi
2021-10-19 11:24 ` Jason Gunthorpe
2021-10-13 9:47 ` [PATCH V1 mlx5-next 12/13] vfio/pci: Add infrastructure to let vfio_pci_core drivers trap device RESET Yishai Hadas
2021-10-15 19:52 ` Alex Williamson
2021-10-15 20:03 ` Jason Gunthorpe
2021-10-15 21:12 ` Alex Williamson
2021-10-17 14:29 ` Yishai Hadas
2021-10-18 12:02 ` Jason Gunthorpe
2021-10-18 13:41 ` Yishai Hadas
2021-10-13 9:47 ` [PATCH V1 mlx5-next 13/13] vfio/mlx5: Trap device RESET and update state accordingly Yishai Hadas
2021-10-13 18:06 ` Jason Gunthorpe
2021-10-14 9:18 ` Yishai Hadas
2021-10-15 19:54 ` Alex Williamson
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=20211015201654.GH2744544@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-pci@vger.kernel.org \
--cc=maorg@nvidia.com \
--cc=mgurtovoy@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=yishaih@nvidia.com \
/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.