All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Robin Murphy <robin.murphy@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
	"ashok.raj@intel.com" <ashok.raj@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH 3/4] iommu: Introduce device fault report API
Date: Fri, 31 May 2019 14:37:59 +0100	[thread overview]
Message-ID: <023acfae-5c93-9e20-8355-5cd7410c15e7@arm.com> (raw)
In-Reply-To: <e56244fd-86fd-1fc9-17f7-d00179d586ac@arm.com>

On 23/05/2019 19:56, Robin Murphy wrote:
> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
>> From: Jacob Pan <jacob.jun.pan@linux.intel.com>
>>
>> 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 of assigned devices.
>>
>> This patch introduces a registration API for device specific fault
>> handlers. This differs from the existing iommu_set_fault_handler/
>> report_iommu_fault infrastructures in several ways:
>> - it allows to report more sophisticated fault events (both
>>    unrecoverable faults and page request faults) due to the nature
>>    of the iommu_fault struct
>> - it is device specific and not domain specific.
>>
>> The current iommu_report_device_fault() implementation only handles
>> the "shoot and forget" unrecoverable fault case. Handling of page
>> request faults or stalled faults will come later.
>>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
>> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>   drivers/iommu/iommu.c | 127 ++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/iommu.h |  29 ++++++++++
>>   2 files changed, 156 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 67ee6623f9b2..d546f7baa0d4 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
>>   		goto err_free_name;
>>   	}
>>   
>> +	dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), GFP_KERNEL);
>> +	if (!dev->iommu_param) {
>> +		ret = -ENOMEM;
>> +		goto err_free_name;
>> +	}
>> +	mutex_init(&dev->iommu_param->lock);
>> +
> 
> Note that this gets a bit tricky when we come to move to move the 
> fwspec/ops/etc. into iommu_param, since that data can have a longer 
> lifespan than the group association. I'd suggest moving this management 
> out to the iommu_{probe,release}_device() level from the start, but 
> maybe we're happy to come back and change things later as necessary.

I'll do that, but iommu_probe_device() might still be too late.
According to of_iommu_configure() there might be cases where
iommu_probe_device() is called after iommu_fwspec_init(). So when moving
everything to iommu_param, we might need to introduce something like
iommu_get_dev_param() which allocates the param if it doesn't exist.

Thanks,
Jean

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Robin Murphy <robin.murphy@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	 "alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"ashok.raj@intel.com" <ashok.raj@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] iommu: Introduce device fault report API
Date: Fri, 31 May 2019 14:37:59 +0100	[thread overview]
Message-ID: <023acfae-5c93-9e20-8355-5cd7410c15e7@arm.com> (raw)
In-Reply-To: <e56244fd-86fd-1fc9-17f7-d00179d586ac@arm.com>

On 23/05/2019 19:56, Robin Murphy wrote:
> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
>> From: Jacob Pan <jacob.jun.pan@linux.intel.com>
>>
>> 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 of assigned devices.
>>
>> This patch introduces a registration API for device specific fault
>> handlers. This differs from the existing iommu_set_fault_handler/
>> report_iommu_fault infrastructures in several ways:
>> - it allows to report more sophisticated fault events (both
>>    unrecoverable faults and page request faults) due to the nature
>>    of the iommu_fault struct
>> - it is device specific and not domain specific.
>>
>> The current iommu_report_device_fault() implementation only handles
>> the "shoot and forget" unrecoverable fault case. Handling of page
>> request faults or stalled faults will come later.
>>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
>> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>   drivers/iommu/iommu.c | 127 ++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/iommu.h |  29 ++++++++++
>>   2 files changed, 156 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 67ee6623f9b2..d546f7baa0d4 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
>>   		goto err_free_name;
>>   	}
>>   
>> +	dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), GFP_KERNEL);
>> +	if (!dev->iommu_param) {
>> +		ret = -ENOMEM;
>> +		goto err_free_name;
>> +	}
>> +	mutex_init(&dev->iommu_param->lock);
>> +
> 
> Note that this gets a bit tricky when we come to move to move the 
> fwspec/ops/etc. into iommu_param, since that data can have a longer 
> lifespan than the group association. I'd suggest moving this management 
> out to the iommu_{probe,release}_device() level from the start, but 
> maybe we're happy to come back and change things later as necessary.

I'll do that, but iommu_probe_device() might still be too late.
According to of_iommu_configure() there might be cases where
iommu_probe_device() is called after iommu_fwspec_init(). So when moving
everything to iommu_param, we might need to introduce something like
iommu_get_dev_param() which allocates the param if it doesn't exist.

Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2019-05-31 13:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 18:06 [PATCH 0/4] iommu: Add device fault reporting API Jean-Philippe Brucker
2019-05-23 18:06 ` Jean-Philippe Brucker
2019-05-23 18:06 ` [PATCH 1/4] driver core: Add per device iommu param Jean-Philippe Brucker
2019-05-23 18:06   ` Jean-Philippe Brucker
2019-05-23 18:06 ` [PATCH 2/4] iommu: Introduce device fault data Jean-Philippe Brucker
2019-05-23 18:06   ` Jean-Philippe Brucker
2019-05-23 18:43   ` Robin Murphy
2019-05-23 18:43     ` Robin Murphy
2019-05-24 13:49     ` Jacob Pan
2019-05-24 13:49       ` Jacob Pan
2019-05-24 16:14       ` Jean-Philippe Brucker
2019-05-24 16:14         ` Jean-Philippe Brucker
2019-05-24 17:44         ` Jacob Pan
2019-05-24 17:44           ` Jacob Pan
2019-05-23 18:06 ` [PATCH 3/4] iommu: Introduce device fault report API Jean-Philippe Brucker
2019-05-23 18:06   ` Jean-Philippe Brucker
2019-05-23 18:56   ` Robin Murphy
2019-05-23 18:56     ` Robin Murphy
2019-05-24 18:00     ` Jacob Pan
2019-05-24 18:00       ` Jacob Pan
2019-05-31 13:37     ` Jean-Philippe Brucker [this message]
2019-05-31 13:37       ` Jean-Philippe Brucker
2019-05-23 18:06 ` [PATCH 4/4] iommu: Add recoverable fault reporting Jean-Philippe Brucker
2019-05-23 18:06   ` Jean-Philippe Brucker
2019-05-24 18:14   ` Jacob Pan
2019-05-24 18:14     ` Jacob Pan
2019-05-31 11:05     ` Jean-Philippe Brucker
2019-05-31 11:05       ` Jean-Philippe Brucker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=023acfae-5c93-9e20-8355-5cd7410c15e7@arm.com \
    --to=jean-philippe.brucker@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=yi.l.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.