> From: Jason Gunthorpe
> Sent: Friday, October 15, 2021 7:10 PM
>
> On Fri, Oct 15, 2021 at 01:29:16AM +, Tian, Kevin wrote:
> > Hi, Jason,
> >
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 29, 2021 8:59 PM
> > >
> > > On Wed, Sep 29, 2021 at 12:38:35AM +, Tian, Kevin
On Fri, Oct 15, 2021 at 01:29:16AM +, Tian, Kevin wrote:
> Hi, Jason,
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 29, 2021 8:59 PM
> >
> > On Wed, Sep 29, 2021 at 12:38:35AM +, Tian, Kevin wrote:
> >
> > > /* If set the driver must call iommu_XX as the first action in
Hi, Jason,
> From: Jason Gunthorpe
> Sent: Wednesday, September 29, 2021 8:59 PM
>
> On Wed, Sep 29, 2021 at 12:38:35AM +, Tian, Kevin wrote:
>
> > /* If set the driver must call iommu_XX as the first action in probe() or
> > * before it attempts to do DMA
> > */
> > bool
On Thu, Sep 30, 2021 at 07:28:18PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 30, 2021 at 01:09:22PM +1000, David Gibson wrote:
>
> > > The *admin* the one responsible to understand the groups, not the
> > > applications. The admin has no idea what a group FD is - they should
> > > be looking at
On Thu, Sep 30, 2021 at 01:09:22PM +1000, David Gibson wrote:
> > The *admin* the one responsible to understand the groups, not the
> > applications. The admin has no idea what a group FD is - they should
> > be looking at the sysfs and seeing the iommu_group directories.
>
> Not just the admin.
On Wed, Sep 29, 2021 at 07:31:08AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Wednesday, September 29, 2021 2:35 PM
> >
> > On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote:
> > > > From: David Gibson
> > > > Sent: Wednesday, September 29, 2021 12:56 PM
> > > >
> > > >
On Wed, Sep 29, 2021 at 09:57:16AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 29, 2021 at 04:35:19PM +1000, David Gibson wrote:
>
> > Yes, exactly. And with a group interface it's obvious it has to
> > understand it. With the non-group interface, you can get to this
> > stage in ignorance of
On Wed, Sep 29, 2021 at 12:38:35AM +, Tian, Kevin wrote:
> /* If set the driver must call iommu_XX as the first action in probe() or
> * before it attempts to do DMA
> */
> bool suppress_dma_owner:1;
It is not "attempts to do DMA" but more "operates the physical device
in any away"
Not
On Wed, Sep 29, 2021 at 04:35:19PM +1000, David Gibson wrote:
> Yes, exactly. And with a group interface it's obvious it has to
> understand it. With the non-group interface, you can get to this
> stage in ignorance of groups. It will even work as long as you are
> lucky enough only to try
> From: David Gibson
> Sent: Wednesday, September 29, 2021 2:35 PM
>
> On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Wednesday, September 29, 2021 12:56 PM
> > >
> > > >
> > > > Unlike vfio, iommufd adopts a device-centric design with all group
On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Wednesday, September 29, 2021 12:56 PM
> >
> > >
> > > Unlike vfio, iommufd adopts a device-centric design with all group
> > > logistics hidden behind the fd. Binding a device to iommufd serves
> > >
> From: David Gibson
> Sent: Wednesday, September 29, 2021 12:56 PM
>
> >
> > Unlike vfio, iommufd adopts a device-centric design with all group
> > logistics hidden behind the fd. Binding a device to iommufd serves
> > as the contract to get security context established (and vice versa
> > for
On Sun, Sep 19, 2021 at 02:38:34PM +0800, Liu Yi L wrote:
> From: Lu Baolu
>
> This extends iommu core to manage security context for passthrough
> devices. Please bear a long explanation for how we reach this design
> instead of managing it solely in iommufd like what vfio does today.
>
>
On 9/29/21 10:29 AM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, September 29, 2021 10:22 AM
On 9/28/21 10:07 PM, Jason Gunthorpe wrote:
On Tue, Sep 28, 2021 at 09:35:05PM +0800, Lu Baolu wrote:
Another issue is, when putting a device into user-dma mode, all devices
belonging to the
> From: Lu Baolu
> Sent: Wednesday, September 29, 2021 10:22 AM
>
> On 9/28/21 10:07 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 28, 2021 at 09:35:05PM +0800, Lu Baolu wrote:
> >> Another issue is, when putting a device into user-dma mode, all devices
> >> belonging to the same iommu group
On 9/28/21 10:07 PM, Jason Gunthorpe wrote:
On Tue, Sep 28, 2021 at 09:35:05PM +0800, Lu Baolu wrote:
Another issue is, when putting a device into user-dma mode, all devices
belonging to the same iommu group shouldn't be bound with a kernel-dma
driver. Kevin's prototype checks this by
> From: Jason Gunthorpe
> Sent: Tuesday, September 28, 2021 10:07 PM
>
> On Tue, Sep 28, 2021 at 09:35:05PM +0800, Lu Baolu wrote:
> > Another issue is, when putting a device into user-dma mode, all devices
> > belonging to the same iommu group shouldn't be bound with a kernel-dma
> > driver.
On Tue, Sep 28, 2021 at 09:35:05PM +0800, Lu Baolu wrote:
> Another issue is, when putting a device into user-dma mode, all devices
> belonging to the same iommu group shouldn't be bound with a kernel-dma
> driver. Kevin's prototype checks this by READ_ONCE(dev->driver). This is
> not lock safe as
Hi Jason,
On 2021/9/28 19:57, Jason Gunthorpe wrote:
On Tue, Sep 28, 2021 at 07:30:41AM +, Tian, Kevin wrote:
Also, don't call it "hint", there is nothing hinty about this, it has
definitive functional impacts.
possibly dma_mode (too broad?) or dma_usage
You just need a flag to
On Tue, Sep 28, 2021 at 07:30:41AM +, Tian, Kevin wrote:
> > Also, don't call it "hint", there is nothing hinty about this, it has
> > definitive functional impacts.
>
> possibly dma_mode (too broad?) or dma_usage
You just need a flag to specify if the driver manages DMA ownership
itself,
> From: Jason Gunthorpe
> Sent: Monday, September 27, 2021 11:09 PM
>
> On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
>
> > +static int iommu_dev_viable(struct device *dev, void *data)
> > +{
> > + enum dma_hint hint = *data;
> > + struct device_driver *drv =
On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> +static int iommu_dev_viable(struct device *dev, void *data)
> +{
> + enum dma_hint hint = *data;
> + struct device_driver *drv = READ_ONCE(dev->driver);
> +
> + /* no conflict if the new device doesn't do DMA */
> +
On Mon, Sep 27, 2021 at 01:00:08PM +, Tian, Kevin wrote:
> > I think for such a narrow usage you should not change the struct
> > device_driver. Just have pci_stub call a function to flip back to user
> > mode.
>
> Here we want to ensure that kernel dma should be blocked
> if the group is
> From: Lu Baolu
> Sent: Monday, September 27, 2021 7:34 PM
>
> On 2021/9/27 17:42, Tian, Kevin wrote:
> > +int iommu_device_set_dma_hint(struct device *dev, enum dma_hint hint)
> > +{
> > + struct iommu_group *group;
> > + int ret;
> > +
> > + group = iommu_group_get(dev);
> > + /* not
> From: Jason Gunthorpe
> Sent: Monday, September 27, 2021 7:54 PM
>
> On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 8:40 PM
> > >
> > > > > Ie the basic flow would see the driver core doing some:
> > > >
> > >
On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 8:40 PM
> >
> > > > Ie the basic flow would see the driver core doing some:
> > >
> > > Just double confirm. Is there concern on having the driver core to
> > > call
On 2021/9/27 17:42, Tian, Kevin wrote:
+int iommu_device_set_dma_hint(struct device *dev, enum dma_hint hint)
+{
+ struct iommu_group *group;
+ int ret;
+
+ group = iommu_group_get(dev);
+ /* not an iommu-probed device */
+ if (!group)
+ return 0;
+
+
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:40 PM
>
> > > Ie the basic flow would see the driver core doing some:
> >
> > Just double confirm. Is there concern on having the driver core to
> > call iommu functions?
>
> It is always an interesting question, but I'd say iommu
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:40 PM
>
> On Wed, Sep 22, 2021 at 01:47:05AM +, Tian, Kevin wrote:
>
> > > IIRC in VFIO the container is the IOAS and when the group goes to
> > > create the device fd it should simply do the
> > > iommu_device_init_user_dma()
On Wed, Sep 22, 2021 at 01:47:05AM +, Tian, Kevin wrote:
> > IIRC in VFIO the container is the IOAS and when the group goes to
> > create the device fd it should simply do the
> > iommu_device_init_user_dma() followed immediately by a call to bind
> > the container IOAS as your #3.
>
> a
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:10 AM
>
> On Sun, Sep 19, 2021 at 02:38:34PM +0800, Liu Yi L wrote:
> > From: Lu Baolu
> >
> > This extends iommu core to manage security context for passthrough
> > devices. Please bear a long explanation for how we reach this
On Sun, Sep 19, 2021 at 02:38:34PM +0800, Liu Yi L wrote:
> From: Lu Baolu
>
> This extends iommu core to manage security context for passthrough
> devices. Please bear a long explanation for how we reach this design
> instead of managing it solely in iommufd like what vfio does today.
>
>
32 matches
Mail list logo
