Re: [Intel-wired-lan] [PATCH iwl-next V2 10/15] ice: save and restore TX queue head

From: Peter Xu <peterx@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Burra, Phani R" <phani.r.burra@intel.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next V2 10/15] ice: save and restore TX queue head
Date: Tue, 4 Jul 2023 13:59:49 -0400	[thread overview]
Message-ID: <ZKReFWNJSVcfhL6y@x1n> (raw)
In-Reply-To: <BN9PR11MB5276AC6CC905A57A370AE48E8C2EA@BN9PR11MB5276.namprd11.prod.outlook.com>

On Tue, Jul 04, 2023 at 07:38:22AM +0000, Tian, Kevin wrote:
> > From: Liu, Yi L <yi.l.liu@intel.com>
> > Sent: Monday, July 3, 2023 8:54 PM
> > 
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > Sent: Wednesday, June 28, 2023 8:39 PM
> > >
> > > On Wed, Jun 28, 2023 at 08:11:07AM +0000, Liu, Yi L wrote:
> > >
> > > > > You can't call VFIO functions from a netdev driver. All this code
> > > > > needs to be moved into the varient driver.
> > > > >
> > > > > This design seems pretty wild to me, it doesn't seem too robust
> > > > > against a hostile VM - eg these DMAs can all fail under guest control,
> > > > > and then what?
> > > > >
> > > > > We also don't have any guarentees defined for the VFIO protocol about
> > > > > what state the vIOMMU will be in prior to reaching RUNNING.
> > > >
> > > > For QEMU, vIOMMU is supposed to be restored prior to devices per
> > > > the below patch. But indeed, there is no guarantee that all VMMs
> > > > will do the same as QEMU does.
> > >
> > > That doesn't seem consistent with how the kernel interface is defined
> > > to work, I wonder why it was done?
> > 
> > Add Peter.

Yi - I think I replied to your private email, I'm not 100% sure this is the
same thing asked?  I hope you received the email.

> > 
> > >
> > > Since it is 2017, I suppose it has to do with internal qemu devices?
> > 
> > Do you mean the devices emulated by QEMU?
> > 
> 
> This sounds counter-intuitive even for emulated devices. vIOMMU is
> involved only when the device wants to access guest memory. But
> by definition the RESUMING path should just restore the device to
> the point where it is stopped. Why would such restore create a
> dependency on vIOMMU state?

For why QEMU migrates vIOMMU earlier than PCI generic devices, I can try to
repeat here: IIRC it's because some device needs dma translations during
post_load(), I forgot which device and why, but it can make some sense to
me if recovering states of the pci device may need help from a translation.

If someone wants to know the details, one can just make vIOMMU prio lower
than pci devices and give it a shot and see what explodes first.

Thanks,

-- 
Peter Xu

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan