On 25/09/2018 23:17, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:58:41 +0100
> Jean-Philippe Brucker wrote:
>
>> Hi Jacob,
>>
>> Just two minor things below, that I noticed while using fault handlers
>> for SVA. From my perspective the series is fine otherwise
>>
>> On 11/05/2018 21:54, Jacob Pan
On Tue, 25 Sep 2018 15:58:41 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> Just two minor things below, that I noticed while using fault handlers
> for SVA. From my perspective the series is fine otherwise
>
> On 11/05/2018 21:54, Jacob Pan wrote:
> > +int iommu_unregister_device_fault_han
Hi Jacob,
Just two minor things below, that I noticed while using fault handlers
for SVA. From my perspective the series is fine otherwise
On 11/05/2018 21:54, Jacob Pan wrote:
> +int iommu_unregister_device_fault_handler(struct device *dev)
> +{
> + struct iommu_param *param = dev->iommu_p
On Fri, 14 Sep 2018 15:24:41 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 5/11/18 10:54 PM, 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 IO
Hi Jacob,
On 5/11/18 10:54 PM, 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 bac
On 07/09/2018 08:11, Auger Eric wrote:
>>> On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote:
On 06/09/2018 10:25, Auger Eric wrote:
>> +mutex_lock(&fparam->lock);
>> +list_add_tail(&evt_pending->list, &fparam->faults);
> same doubt as Yi Liu. You
Hi Jean-Philippe,
On 09/06/2018 07:06 PM, Jean-Philippe Brucker wrote:
> On 06/09/2018 14:14, Auger Eric wrote:
>> 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(&fparam->lock);
> + list
On 06/09/2018 14:14, Auger Eric wrote:
> 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(&fparam->lock);
+ list_add_tail(&evt_pending->list, &fparam->faults);
>>> same doubt as Yi Liu. You
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(&fparam->lock);
>>> + list_add_tail(&evt_pending->list, &fparam->faults);
>> same doubt as Yi Liu. You cannot rely on the userspace willingness to
>>
On 06/09/2018 10:25, Auger Eric wrote:
>> +mutex_lock(&fparam->lock);
>> +list_add_tail(&evt_pending->list, &fparam->faults);
> same doubt as Yi Liu. You cannot rely on the userspace willingness to
> void the queue and deallocate this memory.
>
> SMMUv3 holds a queue of eve
Hi Jacob,
On 05/11/2018 10:54 PM, 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
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 rel
> 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 iommu_f
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 allocate
> 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
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
>>
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.
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 t
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
19 matches
Mail list logo
