On Wed, 12 Jun 2019 15:11:43 +0200
Joerg Roedel wrote:
> On Wed, Jun 12, 2019 at 12:54:51PM +0100, Jean-Philippe Brucker wrote:
> > Thanks! As discussed I think we need to add padding into the
> > iommu_fault structure before this reaches mainline, to make the
> > UAPI easier to extend in the
On Wed, Jun 12, 2019 at 12:54:51PM +0100, Jean-Philippe Brucker wrote:
> Thanks! As discussed I think we need to add padding into the iommu_fault
> structure before this reaches mainline, to make the UAPI easier to
> extend in the future. It's already possible to extend but requires
> introducing
On 12/06/2019 09:19, Joerg Roedel wrote:
> On Mon, Jun 03, 2019 at 03:57:45PM +0100, Jean-Philippe Brucker wrote:
>> Jacob Pan (3):
>> driver core: Add per device iommu param
>> iommu: Introduce device fault data
>> iommu: Introduce device fault report API
>>
>> Jean-Philippe Brucker (1):
>>
On Mon, Jun 03, 2019 at 03:57:45PM +0100, Jean-Philippe Brucker wrote:
> Jacob Pan (3):
> driver core: Add per device iommu param
> iommu: Introduce device fault data
> iommu: Introduce device fault report API
>
> Jean-Philippe Brucker (1):
> iommu: Add recoverable fault reporting
>
>
On 03/06/2019 22:59, Jacob Pan wrote:
> On Mon, 3 Jun 2019 15:57:45 +0100
> Jean-Philippe Brucker wrote:
>
>> Allow device drivers and VFIO to get notified on IOMMU translation
>> fault, and handle recoverable faults (PCI PRI). Several series require
>> this API (Intel VT-d and Arm SMMUv3
On Mon, 3 Jun 2019 15:57:45 +0100
Jean-Philippe Brucker wrote:
> Allow device drivers and VFIO to get notified on IOMMU translation
> fault, and handle recoverable faults (PCI PRI). Several series require
> this API (Intel VT-d and Arm SMMUv3 nested support, as well as the
> generic host SVA
