On Fri, Jul 29, 2022 at 04:24:36AM +, Tian, Kevin wrote:
> > It is a POWER specific thing with one not-so-obvious consequence of each
> > window having an independent page size (fixed at the moment or creation)
> > and (most likely) different page size, like, 4K vs. 2M.
>
> page size is anyway
> From: Alexey Kardashevskiy
> Sent: Friday, July 29, 2022 11:50 AM
>
>
> On 29/07/2022 13:10, Tian, Kevin wrote:
> >> From: Oliver O'Halloran
> >> Sent: Friday, July 29, 2022 10:53 AM
> >>
> >> On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy
> wrote:
> >>>
> >>> *snip*
> >>>
> >>> About
On 29/07/2022 13:10, Tian, Kevin wrote:
From: Oliver O'Halloran
Sent: Friday, July 29, 2022 10:53 AM
On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy wrote:
*snip*
About this. If a platform has a concept of explicit DMA windows (2 or
more), is it one domain with 2 windows or 2 domai
> From: Oliver O'Halloran
> Sent: Friday, July 29, 2022 10:53 AM
>
> On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy wrote:
> >
> > *snip*
> >
> > About this. If a platform has a concept of explicit DMA windows (2 or
> > more), is it one domain with 2 windows or 2 domains with one window
>
On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy wrote:
>
> *snip*
>
> About this. If a platform has a concept of explicit DMA windows (2 or
> more), is it one domain with 2 windows or 2 domains with one window each?
>
> If it is 2 windows, iommu_domain_ops misses windows manipulation
> callb
On 08/07/2022 17:32, Tian, Kevin wrote:
From: Alexey Kardashevskiy
Sent: Friday, July 8, 2022 2:35 PM
On 7/8/22 15:00, Alexey Kardashevskiy wrote:
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to a
On Tue, Jul 12, 2022 at 12:27:17PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 7/12/22 04:46, Jason Gunthorpe wrote:
> > On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
> >
> > > I really think that for 5.19 we should really move this blocked domain
> > > business to Type1
On 7/12/22 04:46, Jason Gunthorpe wrote:
On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
I really think that for 5.19 we should really move this blocked domain
business to Type1 like this:
https://github.com/aik/linux/commit/96f80c8db03b181398ad355f6f90e574c3ada4bf
T
On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
> I really think that for 5.19 we should really move this blocked domain
> business to Type1 like this:
>
> https://github.com/aik/linux/commit/96f80c8db03b181398ad355f6f90e574c3ada4bf
This creates the same security bug for po
On 10/07/2022 22:32, Alexey Kardashevskiy wrote:
On 10/07/2022 16:29, Jason Gunthorpe wrote:
On Sat, Jul 09, 2022 at 12:58:00PM +1000, Alexey Kardashevskiy wrote:
driver->ops->attach_group on POWER attaches a group so VFIO claims
ownership
over a group, not devices. Underlying API
(pnv_io
On 10/07/2022 16:29, Jason Gunthorpe wrote:
On Sat, Jul 09, 2022 at 12:58:00PM +1000, Alexey Kardashevskiy wrote:
driver->ops->attach_group on POWER attaches a group so VFIO claims ownership
over a group, not devices. Underlying API (pnv_ioda2_take_ownership()) does
not need to keep track
On Sat, Jul 09, 2022 at 12:58:00PM +1000, Alexey Kardashevskiy wrote:
> driver->ops->attach_group on POWER attaches a group so VFIO claims ownership
> over a group, not devices. Underlying API (pnv_ioda2_take_ownership()) does
> not need to keep track of the state, it is one group, one ownership
On 08/07/2022 21:55, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
to do nothing as tce_iommu_take_ownership() and
tce_iommu_take_ownership_ddw() take care of not having
On Fri, Jul 08, 2022 at 11:32:58PM +1000, Alexey Kardashevskiy wrote:
> > For power the default domain should be NULL
> >
> > NULL means that the platform is using the group to provide its DMA
> > ops. IIRC this patch was already setup correctly to do this?
> >
> > The transition from NULL to blo
On 08/07/2022 23:19, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 11:10:07PM +1000, Alexey Kardashevskiy wrote:
On 08/07/2022 21:55, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
For now I'll add a comment in spapr_tce_iommu_attach_dev() t
On Fri, Jul 08, 2022 at 11:10:07PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 08/07/2022 21:55, Jason Gunthorpe wrote:
> > On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
> >
> > > For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
> > > to do nothi
On 08/07/2022 21:55, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
to do nothing as tce_iommu_take_ownership() and
tce_iommu_take_ownership_ddw() take care of not having
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
> For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
> to do nothing as tce_iommu_take_ownership() and
> tce_iommu_take_ownership_ddw() take care of not having active DMA mappings.
That will still cause
> From: Alexey Kardashevskiy
> Sent: Friday, July 8, 2022 5:46 PM
>
> >>>
> >>> In general, is "domain" something from hardware or it is a software
> >>> concept? Thanks,
> >>>
> >
> > 'domain' is a software concept to represent the hardware I/O page
> > table. A blocking domain means all DMAs fr
On 08/07/2022 17:32, Tian, Kevin wrote:
From: Alexey Kardashevskiy
Sent: Friday, July 8, 2022 2:35 PM
On 7/8/22 15:00, Alexey Kardashevskiy wrote:
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to a
> From: Alexey Kardashevskiy
> Sent: Friday, July 8, 2022 2:35 PM
> On 7/8/22 15:00, Alexey Kardashevskiy wrote:
> >
> >
> > On 7/8/22 01:10, Jason Gunthorpe wrote:
> >> On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
> >>> Historically PPC64 managed to avoid using iommu_ops.
On 7/8/22 15:00, Alexey Kardashevskiy wrote:
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
th
On 7/8/22 01:10, Jason Gunthorpe wrote:
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though h
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
> Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development though has added a coherency
> capability check
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of VFIO and essentially disabled
VFIO on PPC64; the simila
25 matches
Mail list logo