From: Jason Gunthorpe <jgg@nvidia.com>
To: "Cao, Yahui" <yahui.cao@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next V2 10/15] ice: save and restore TX queue head
Date: Mon, 3 Jul 2023 18:03:51 -0300 [thread overview]
Message-ID: <ZKM3t7FDH09zeJg1@nvidia.com> (raw)
In-Reply-To: <ba8ccf89-6045-4fd7-02b9-308d50226251@intel.com>
On Mon, Jul 03, 2023 at 01:27:51PM +0800, Cao, Yahui wrote:
> > > You can't call VFIO functions from a netdev driver. All this code
> > > needs to be moved into the varient driver.
>
> Will move vfio_dma_rw() into vfio driver and passing callback function into
> netdev driver
Please make proper layers, you should not need to stitch your driver
together with weird function pointers.
> > > We also don't have any guarentees defined for the VFIO protocol about
> > > what state the vIOMMU will be in prior to reaching RUNNING.
> > This is a good point. Actually it's not just a gap on vIOMMU. it's kind
> > of a dependency on IOMMUFD no matter the IOAS which the migrated
> > device is currently attached to is GPA or GIOVA. The device state can
> > be restored only after IOMMUFD is fully recovered and the device is
> > re-attached to the IOAS.
> >
> > Need a way for migration driver to advocate such dependency to the user.
>
> Since this part is new to me, may need further guidance on how to resolve
> the dependency from you and other community experts.
Personally I'm quite uncomfortable with a driver that tries to work
this way, I'm not sure we should encourage this. Can Intel really be
convincing that this is safe and correct?
Jason
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Cao, Yahui" <yahui.cao@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Lingyu" <lingyu.liu@intel.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next V2 10/15] ice: save and restore TX queue head
Date: Mon, 3 Jul 2023 18:03:51 -0300 [thread overview]
Message-ID: <ZKM3t7FDH09zeJg1@nvidia.com> (raw)
In-Reply-To: <ba8ccf89-6045-4fd7-02b9-308d50226251@intel.com>
On Mon, Jul 03, 2023 at 01:27:51PM +0800, Cao, Yahui wrote:
> > > You can't call VFIO functions from a netdev driver. All this code
> > > needs to be moved into the varient driver.
>
> Will move vfio_dma_rw() into vfio driver and passing callback function into
> netdev driver
Please make proper layers, you should not need to stitch your driver
together with weird function pointers.
> > > We also don't have any guarentees defined for the VFIO protocol about
> > > what state the vIOMMU will be in prior to reaching RUNNING.
> > This is a good point. Actually it's not just a gap on vIOMMU. it's kind
> > of a dependency on IOMMUFD no matter the IOAS which the migrated
> > device is currently attached to is GPA or GIOVA. The device state can
> > be restored only after IOMMUFD is fully recovered and the device is
> > re-attached to the IOAS.
> >
> > Need a way for migration driver to advocate such dependency to the user.
>
> Since this part is new to me, may need further guidance on how to resolve
> the dependency from you and other community experts.
Personally I'm quite uncomfortable with a driver that tries to work
this way, I'm not sure we should encourage this. Can Intel really be
convincing that this is safe and correct?
Jason
next prev parent reply other threads:[~2023-07-03 21:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 9:10 [Intel-wired-lan] [PATCH iwl-next V2 00/15] Add E800 live migration driver Lingyu Liu
2023-06-21 9:10 ` [Intel-wired-lan] [PATCH iwl-next V2 01/15] ice: Fix missing legacy 32byte RXDID in the supported bitmap Lingyu Liu
2023-06-21 9:10 ` [Intel-wired-lan] [PATCH iwl-next V2 02/15] ice: add function to get rxq context Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 03/15] ice: check VF migration status before sending messages to VF Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 04/15] ice: add migration init field and helper functions Lingyu Liu
2023-06-21 13:35 ` Jason Gunthorpe
2023-06-27 7:50 ` Cao, Yahui
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 05/15] ice: save VF messages as device state Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 06/15] ice: save and restore " Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 07/15] ice: do not notify VF link state during migration Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 08/15] ice: change VSI id in virtual channel message after migration Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 09/15] ice: save and restore RX queue head Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 10/15] ice: save and restore TX " Lingyu Liu
2023-06-21 14:37 ` Jason Gunthorpe
2023-06-27 6:55 ` Tian, Kevin
2023-06-27 6:55 ` Tian, Kevin
2023-07-03 5:27 ` Cao, Yahui
2023-07-03 5:27 ` Cao, Yahui
2023-07-03 21:03 ` Jason Gunthorpe [this message]
2023-07-03 21:03 ` Jason Gunthorpe
2023-07-04 7:35 ` Tian, Kevin
2023-07-04 7:35 ` Tian, Kevin
2023-06-28 8:11 ` Liu, Yi L
2023-06-28 12:39 ` Jason Gunthorpe
2023-07-03 12:54 ` Liu, Yi L
2023-07-04 7:38 ` Tian, Kevin
2023-07-04 17:59 ` Peter Xu
2023-07-10 15:54 ` Jason Gunthorpe
2023-07-17 21:43 ` Peter Xu
2023-07-18 15:38 ` Jason Gunthorpe
2023-07-18 17:36 ` Peter Xu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 11/15] ice: stop device before saving device states Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 12/15] ice: mask VF advanced capabilities if live migration is activated Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 13/15] vfio/ice: implement vfio_pci driver for E800 devices Lingyu Liu
2023-06-21 14:23 ` Jason Gunthorpe
2023-06-27 9:00 ` Liu, Lingyu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 14/15] vfio: Expose vfio_device_has_container() Lingyu Liu
2023-06-21 9:11 ` [Intel-wired-lan] [PATCH iwl-next V2 15/15] vfio/ice: support iommufd vfio compat mode Lingyu Liu
2023-06-21 14:40 ` Jason Gunthorpe
2023-06-27 8:09 ` Cao, Yahui
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=ZKM3t7FDH09zeJg1@nvidia.com \
--to=jgg@nvidia.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=yahui.cao@intel.com \
--cc=yi.l.liu@intel.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.