linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Kumar Gautam <vivek.gautam@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org,
	virtualization@lists.linux-foundation.org, joro@8bytes.org,
	will.deacon@arm.com, mst@redhat.com, robin.murphy@arm.com,
	eric.auger@redhat.com, alex.williamson@redhat.com,
	kevin.tian@intel.com, jacob.jun.pan@linux.intel.com,
	yi.l.liu@intel.com, lorenzo.pieralisi@arm.com,
	shameerali.kolothum.thodi@huawei.com
Subject: Re: [PATCH RFC v1 15/15] iommu/virtio: Update fault type and reason info for viommu fault
Date: Fri, 12 Mar 2021 18:39:05 +0530	[thread overview]
Message-ID: <d8a81406-12c6-a5e1-7297-49c1a0a800ab@arm.com> (raw)
In-Reply-To: <YD/GjQIKkaJ5+UJM@myrica>



On 3/3/21 10:55 PM, Jean-Philippe Brucker wrote:
> On Fri, Jan 15, 2021 at 05:43:42PM +0530, Vivek Gautam wrote:
>> Fault type information can tell about a page request fault or
>> an unreceoverable fault, and further additions to fault reasons
>> and the related PASID information can help in handling faults
>> efficiently.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam@arm.com>
>> Cc: Joerg Roedel <joro@8bytes.org>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> Cc: Eric Auger <eric.auger@redhat.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>> ---
>>   drivers/iommu/virtio-iommu.c      | 27 +++++++++++++++++++++++++--
>>   include/uapi/linux/virtio_iommu.h | 13 ++++++++++++-
>>   2 files changed, 37 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
>> index 9cc3d35125e9..10ef9e98214a 100644
>> --- a/drivers/iommu/virtio-iommu.c
>> +++ b/drivers/iommu/virtio-iommu.c
>> @@ -652,9 +652,16 @@ static int viommu_fault_handler(struct viommu_dev *viommu,
>>   	char *reason_str;
>>   
>>   	u8 reason	= fault->reason;
>> +	u16 type	= fault->flt_type;
>>   	u32 flags	= le32_to_cpu(fault->flags);
>>   	u32 endpoint	= le32_to_cpu(fault->endpoint);
>>   	u64 address	= le64_to_cpu(fault->address);
>> +	u32 pasid	= le32_to_cpu(fault->pasid);
>> +
>> +	if (type == VIRTIO_IOMMU_FAULT_F_PAGE_REQ) {
>> +		dev_info(viommu->dev, "Page request fault - unhandled\n");
>> +		return 0;
>> +	}
>>   
>>   	switch (reason) {
>>   	case VIRTIO_IOMMU_FAULT_R_DOMAIN:
>> @@ -663,6 +670,21 @@ static int viommu_fault_handler(struct viommu_dev *viommu,
>>   	case VIRTIO_IOMMU_FAULT_R_MAPPING:
>>   		reason_str = "page";
>>   		break;
>> +	case VIRTIO_IOMMU_FAULT_R_WALK_EABT:
>> +		reason_str = "page walk external abort";
>> +		break;
>> +	case VIRTIO_IOMMU_FAULT_R_PTE_FETCH:
>> +		reason_str = "pte fetch";
>> +		break;
>> +	case VIRTIO_IOMMU_FAULT_R_PERMISSION:
>> +		reason_str = "permission";
>> +		break;
>> +	case VIRTIO_IOMMU_FAULT_R_ACCESS:
>> +		reason_str = "access";
>> +		break;
>> +	case VIRTIO_IOMMU_FAULT_R_OOR_ADDRESS:
>> +		reason_str = "output address";
>> +		break;
>>   	case VIRTIO_IOMMU_FAULT_R_UNKNOWN:
>>   	default:
>>   		reason_str = "unknown";
>> @@ -671,8 +693,9 @@ static int viommu_fault_handler(struct viommu_dev *viommu,
>>   
>>   	/* TODO: find EP by ID and report_iommu_fault */
>>   	if (flags & VIRTIO_IOMMU_FAULT_F_ADDRESS)
>> -		dev_err_ratelimited(viommu->dev, "%s fault from EP %u at %#llx [%s%s%s]\n",
>> -				    reason_str, endpoint, address,
>> +		dev_err_ratelimited(viommu->dev,
>> +				    "%s fault from EP %u PASID %u at %#llx [%s%s%s]\n",
>> +				    reason_str, endpoint, pasid, address,
>>   				    flags & VIRTIO_IOMMU_FAULT_F_READ ? "R" : "",
>>   				    flags & VIRTIO_IOMMU_FAULT_F_WRITE ? "W" : "",
>>   				    flags & VIRTIO_IOMMU_FAULT_F_EXEC ? "X" : "");
>> diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
>> index 608c8d642e1f..a537d82777f7 100644
>> --- a/include/uapi/linux/virtio_iommu.h
>> +++ b/include/uapi/linux/virtio_iommu.h
>> @@ -290,19 +290,30 @@ struct virtio_iommu_req_invalidate {
>>   #define VIRTIO_IOMMU_FAULT_R_UNKNOWN		0
>>   #define VIRTIO_IOMMU_FAULT_R_DOMAIN		1
>>   #define VIRTIO_IOMMU_FAULT_R_MAPPING		2
>> +#define VIRTIO_IOMMU_FAULT_R_WALK_EABT		3
>> +#define VIRTIO_IOMMU_FAULT_R_PTE_FETCH		4
>> +#define VIRTIO_IOMMU_FAULT_R_PERMISSION		5
>> +#define VIRTIO_IOMMU_FAULT_R_ACCESS		6
>> +#define VIRTIO_IOMMU_FAULT_R_OOR_ADDRESS	7
>>   
>>   #define VIRTIO_IOMMU_FAULT_F_READ		(1 << 0)
>>   #define VIRTIO_IOMMU_FAULT_F_WRITE		(1 << 1)
>>   #define VIRTIO_IOMMU_FAULT_F_EXEC		(1 << 2)
>>   #define VIRTIO_IOMMU_FAULT_F_ADDRESS		(1 << 8)
>>   
>> +#define VIRTIO_IOMMU_FAULT_F_DMA_UNRECOV	1
>> +#define VIRTIO_IOMMU_FAULT_F_PAGE_REQ		2
> 
> Currently all reported faults are unrecoverable, so to be consistent
> DMA_UNRECOV should be 0. But I'd prefer having just a new "page request"
> flag in the flags field, instead of the flt_type field.

Yea, looking at what I am currently trying as well - handle page-request 
and leave all other faults as unrecoverable - I will add the page 
request flag in the structure.

> 
> For page requests we'll also need a 16-bit fault ID field to store the PRI
> "page request group index" or the stall "stag". "last" and "privileged"
> flags as well, to match the PRI page request. And a new command to
> complete a page fault.

Right, will add the fields as suggested.
To complete the page request we would also need to send the response 
back to the host from virtio backend when handling page request. So the 
virtio command should also be accompanied with a vfio api to send the 
page request response back to the host. Isn't it?
This is where the host smmuv3 can send PRI_RESP command to the device to 
complete the page fault.

> 
>> +
>>   struct virtio_iommu_fault {
>>   	__u8					reason;
>> -	__u8					reserved[3];
>> +	__le16					flt_type;
>> +	__u8					reserved;
>>   	__le32					flags;
>>   	__le32					endpoint;
>>   	__u8					reserved2[4];
> 
> Why not replace reserved2 with the pasid?  It fits perfectly :)

Sure, will do it.

Thanks & regards
Vivek

> 
> Thanks,
> Jean
> 
>>   	__le64					address;
>> +	__le32					pasid;
>> +	__u8					reserved3[4];
>>   };
>>   
>>   #endif
>> -- 
>> 2.17.1
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-12 13:11 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 12:13 [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 01/15] iommu/arm-smmu-v3: Create a Context Descriptor library Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 02/15] iommu: Add a simple PASID table library Vivek Gautam
2021-03-03 17:11   ` Jean-Philippe Brucker
2021-03-12 12:47     ` Vivek Kumar Gautam
2021-03-29 16:25       ` Jean-Philippe Brucker
2021-01-15 12:13 ` [PATCH RFC v1 03/15] iommu/arm-smmu-v3: Update drivers to work with iommu-pasid-table Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 04/15] iommu/arm-smmu-v3: Update CD base address info for user-space Vivek Gautam
2021-03-03 17:14   ` Jean-Philippe Brucker
2021-03-12 12:31     ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 05/15] iommu/arm-smmu-v3: Set sync op from consumer driver of cd-lib Vivek Gautam
2021-03-03 17:15   ` Jean-Philippe Brucker
2021-03-12 12:49     ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 06/15] iommu/virtio: Add headers for table format probing Vivek Gautam
2021-03-03 17:17   ` Jean-Philippe Brucker
2021-03-12 12:54     ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 07/15] iommu/virtio: Add " Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 08/15] iommu: Add asid_bits to arm smmu-v3 stage1 table info Vivek Gautam
2021-03-03 17:18   ` Jean-Philippe Brucker
2021-03-12 12:57     ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 09/15] iommu/virtio: Update table format probing header Vivek Gautam
2021-03-03 17:21   ` Jean-Philippe Brucker
2021-03-12 12:58     ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 10/15] iommu/virtio: Prepare to add attach pasid table infrastructure Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 11/15] iommu/virtio: Add headers for binding pasid table in iommu Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 12/15] iommu/virtio: Add support for INVALIDATE request Vivek Gautam
2021-03-03 18:28   ` Jacob Pan
2021-03-04  5:58     ` Tian, Kevin
2021-03-04  6:16       ` Vivek Kumar Gautam
2021-01-15 12:13 ` [PATCH RFC v1 13/15] iommu/virtio: Attach Arm PASID tables when available Vivek Gautam
2021-03-03 17:25   ` Jean-Philippe Brucker
2021-03-12 13:29     ` Vivek Kumar Gautam
2021-03-29 16:21       ` Jean-Philippe Brucker
2021-01-15 12:13 ` [PATCH RFC v1 14/15] iommu/virtio: Add support for Arm LPAE page table format Vivek Gautam
2021-01-15 12:13 ` [PATCH RFC v1 15/15] iommu/virtio: Update fault type and reason info for viommu fault Vivek Gautam
2021-03-03 17:25   ` Jean-Philippe Brucker
2021-03-12 13:09     ` Vivek Kumar Gautam [this message]
2021-03-29 16:23       ` Jean-Philippe Brucker
2021-04-06  6:24         ` Vivek Kumar Gautam
2021-01-19  9:03 ` [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm Auger Eric
2021-01-21 17:34   ` Vivek Kumar Gautam
2021-01-22 15:49     ` Shameerali Kolothum Thodi
2021-01-25 12:55       ` Vivek Kumar Gautam
2021-01-25  8:43     ` Auger Eric

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=d8a81406-12c6-a5e1-7297-49c1a0a800ab@arm.com \
    --to=vivek.gautam@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mst@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will.deacon@arm.com \
    --cc=yi.l.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).