> 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.
>
>
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.
Devices which cannot be isolated from each other are organized into an
iommu
33 matches
Mail list logo
