Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi Jean-Philippe, On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote: > On 06/09/2018 10:25, Auger Eric wrote: >>> + mutex_lock(>lock); >>> + list_add_tail(_pending->list, >faults); >> same doubt as Yi Liu. You cannot rely on the userspace willingness to >> void the queue and

Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi Jean-Philippe, On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote: > On 06/09/2018 10:25, Auger Eric wrote: >>> + mutex_lock(>lock); >>> + list_add_tail(_pending->list, >faults); >> same doubt as Yi Liu. You cannot rely on the userspace willingness to >> void the queue and

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Thu, 17 May 2018 23:22:43 + "Liu, Yi L" wrote: > > So as long as in-kernel PRQ handling can do queuing, there is no > > need for queuing in the host reporting path. > > Will it affect current interface? Here the handler only get an "evt" > per a PRQ IRQ. And I

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Thu, 17 May 2018 23:22:43 + "Liu, Yi L" wrote: > > So as long as in-kernel PRQ handling can do queuing, there is no > > need for queuing in the host reporting path. > > Will it affect current interface? Here the handler only get an "evt" > per a PRQ IRQ. And I suppose vfio needs not

RE: [PATCH v5 13/23] iommu: introduce device fault report API

> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Thursday, May 17, 2018 11:59 PM > On Thu, 17 May 2018 11:41:56 + > "Liu, Yi L" wrote: > > > > +int iommu_report_device_fault(struct device *dev, struct > > > +iommu_fault_event *evt) { > > > + int ret = 0; >

RE: [PATCH v5 13/23] iommu: introduce device fault report API

> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Thursday, May 17, 2018 11:59 PM > On Thu, 17 May 2018 11:41:56 + > "Liu, Yi L" wrote: > > > > +int iommu_report_device_fault(struct device *dev, struct > > > +iommu_fault_event *evt) { > > > + int ret = 0; > > > + struct

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Thu, 17 May 2018 11:41:56 + "Liu, Yi L" wrote: > > +int iommu_report_device_fault(struct device *dev, struct > > +iommu_fault_event *evt) { > > + int ret = 0; > > + struct iommu_fault_event *evt_pending; > > + struct iommu_fault_param *fparam; > > + > > + /*

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Thu, 17 May 2018 11:41:56 + "Liu, Yi L" wrote: > > +int iommu_report_device_fault(struct device *dev, struct > > +iommu_fault_event *evt) { > > + int ret = 0; > > + struct iommu_fault_event *evt_pending; > > + struct iommu_fault_param *fparam; > > + > > + /* iommu_param is

RE: [PATCH v5 13/23] iommu: introduce device fault report API

> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Saturday, May 12, 2018 4:54 AM > > Traditionally, device specific faults are detected and handled within their > own device > drivers. When IOMMU is enabled, faults such as DMA related transactions are > detected by IOMMU. There is

RE: [PATCH v5 13/23] iommu: introduce device fault report API

> From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > Sent: Saturday, May 12, 2018 4:54 AM > > Traditionally, device specific faults are detected and handled within their > own device > drivers. When IOMMU is enabled, faults such as DMA related transactions are > detected by IOMMU. There is

Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi, On 05/15/2018 04:55 AM, Jacob Pan wrote: > On Mon, 14 May 2018 14:01:06 +0800 > Lu Baolu wrote: > >> Hi, >> >> On 05/12/2018 04:54 AM, Jacob Pan wrote: >>> Traditionally, device specific faults are detected and handled >>> within their own device drivers. When IOMMU

Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi, On 05/15/2018 04:55 AM, Jacob Pan wrote: > On Mon, 14 May 2018 14:01:06 +0800 > Lu Baolu wrote: > >> Hi, >> >> On 05/12/2018 04:54 AM, Jacob Pan wrote: >>> Traditionally, device specific faults are detected and handled >>> within their own device drivers. When IOMMU is enabled, faults such

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Mon, 14 May 2018 14:01:06 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:54 AM, Jacob Pan wrote: > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related

Re: [PATCH v5 13/23] iommu: introduce device fault report API

On Mon, 14 May 2018 14:01:06 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:54 AM, Jacob Pan wrote: > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related transactions are detected by IOMMU.

Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi, On 05/12/2018 04:54 AM, Jacob Pan wrote: > Traditionally, device specific faults are detected and handled within > their own device drivers. When IOMMU is enabled, faults such as DMA > related transactions are detected by IOMMU. There is no generic > reporting mechanism to report faults back

Re: [PATCH v5 13/23] iommu: introduce device fault report API

Hi, On 05/12/2018 04:54 AM, Jacob Pan wrote: > Traditionally, device specific faults are detected and handled within > their own device drivers. When IOMMU is enabled, faults such as DMA > related transactions are detected by IOMMU. There is no generic > reporting mechanism to report faults back

[PATCH v5 13/23] iommu: introduce device fault report API

Traditionally, device specific faults are detected and handled within their own device drivers. When IOMMU is enabled, faults such as DMA related transactions are detected by IOMMU. There is no generic reporting mechanism to report faults back to the in-kernel device driver or the guest OS in case

[PATCH v5 13/23] iommu: introduce device fault report API

Traditionally, device specific faults are detected and handled within their own device drivers. When IOMMU is enabled, faults such as DMA related transactions are detected by IOMMU. There is no generic reporting mechanism to report faults back to the in-kernel device driver or the guest OS in case