All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
	lorenzo.pieralisi@arm.com, joro@8bytes.org,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	kevin.tian@intel.com, jacob.jun.pan@linux.intel.com,
	robh+dt@kernel.org, Jonathan.Cameron@huawei.com,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	shameerali.kolothum.thodi@huawei.com,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org,
	baolu.lu@linux.intel.com
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 14:16:16 +0100	[thread overview]
Message-ID: <47a65f65-26cb-de27-049a-48f2d083964a@redhat.com> (raw)
In-Reply-To: <YBfiIwdVP1dXg7Yt@myrica>

Hi Jean,

On 2/1/21 12:12 PM, Jean-Philippe Brucker wrote:
> On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
>> Hi Jean,
>>
>> Some rather minor comments§questions below that may not justify a respin.
>>
>> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
>>> -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
>>> +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
>>>  {
>>> -	return false;
>>> +	/* We're not keeping track of SIDs in fault events */
>> shall we? [*] below
> 
> That would require storing the incoming SID into the iommu_fault_event
> struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
> don't think it's needed for existing devices.
OK
> 
>>> +	if (master->num_streams != 1)
>>> +		return false;
> [...]
>>> +static int arm_smmu_page_response(struct device *dev,
>>> +				  struct iommu_fault_event *unused,
>>> +				  struct iommu_page_response *resp)
>>> +{
>>> +	struct arm_smmu_cmdq_ent cmd = {0};
>>> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
>>> +	int sid = master->streams[0].id;
>> [*]
>>> +
>>> +	if (master->stall_enabled) {
>>> +		cmd.opcode		= CMDQ_OP_RESUME;
>>> +		cmd.resume.sid		= sid;
>>> +		cmd.resume.stag		= resp->grpid;
>>> +		switch (resp->code) {
>>> +		case IOMMU_PAGE_RESP_INVALID:
>> add fallthrough?
> 
> I think fallthrough is mainly useful to tell reader and compiler that a
> break was omitted on purpose. When two cases are stuck together the intent
> to merge the flow is clear enough in my opinion. GCC's
> -Wimplicit-fallthrough doesn't warn in this case.
OK
> 
>>> +		case IOMMU_PAGE_RESP_FAILURE:
>>> +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
>>> +			break;
> [...]
>>> +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
>>> +{
>>> +	int ret;
>>> +	u32 reason;
>>> +	u32 perm = 0;
>>> +	struct arm_smmu_master *master;
>>> +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
>>> +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
>>> +	struct iommu_fault_event fault_evt = { };
>>> +	struct iommu_fault *flt = &fault_evt.fault;
>>> +
>>> +	/* Stage-2 is always pinned at the moment */
>>> +	if (evt[1] & EVTQ_1_S2)
>>> +		return -EFAULT;
>>> +
>>> +	master = arm_smmu_find_master(smmu, sid);
>>> +	if (!master)
>>> +		return -EINVAL;
>>> +
>>> +	if (evt[1] & EVTQ_1_RnW)
>>> +		perm |= IOMMU_FAULT_PERM_READ;
>>> +	else
>>> +		perm |= IOMMU_FAULT_PERM_WRITE;
>>> +
>>> +	if (evt[1] & EVTQ_1_InD)
>>> +		perm |= IOMMU_FAULT_PERM_EXEC;
>>> +
>>> +	if (evt[1] & EVTQ_1_PnU)
>>> +		perm |= IOMMU_FAULT_PERM_PRIV;
>>> +
>>> +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
>>> +	case EVT_ID_TRANSLATION_FAULT:
>>> +	case EVT_ID_ADDR_SIZE_FAULT:
>>> +	case EVT_ID_ACCESS_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
>> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
>> /* access flag check failed */"
> 
> Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
> corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?
yes it dies
> 
> By the way the wording on those two fault reasons, "access flag" and
> "stage", seems arch-specific - x86 names are "accessed flag" and "level".
> 
>>> +		break;
>>> +	case EVT_ID_PERMISSION_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PERMISSION;
>>> +		break;
>>> +	default:
>>> +		return -EOPNOTSUPP;
>>> +	}
>>> +
>>> +	if (evt[1] & EVTQ_1_STALL) {
>>> +		flt->type = IOMMU_FAULT_PAGE_REQ;
>>> +		flt->prm = (struct iommu_fault_page_request) {
>>> +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
>>> +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +		};
>>> +
>>> +		if (ssid_valid) {
>>> +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
>>> +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
>>> +		}
>>> +	} else {
>>> +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
>>> +		flt->event = (struct iommu_fault_unrecoverable) {
>>> +			.reason = reason,
>>> +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
>>> +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
>> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
>> unrecoverable faults feature the IPA field which is UNKNOWN for S1
>> translations. fetch_addr rather was
>> corresponding to WALK_EABT.Fetch_addr to me.
> 
> Right I should drop the IPA part entirely, since we don't report S2 faults
> in this patch.
OK

But as I mentioned this can be fixed separately if you don't have other
comments on this version.

Thanks

Eric
> 
> Thanks,
> Jean
> 
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
>>> +		};
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com,
	linux-acpi@vger.kernel.org, robin.murphy@arm.com,
	rjw@rjwysocki.net, robh+dt@kernel.org, sudeep.holla@arm.com,
	vivek.gautam@arm.com, iommu@lists.linux-foundation.org,
	linux-accelerators@lists.ozlabs.org, guohanjun@huawei.com,
	zhangfei.gao@linaro.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, lenb@kernel.org
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 14:16:16 +0100	[thread overview]
Message-ID: <47a65f65-26cb-de27-049a-48f2d083964a@redhat.com> (raw)
In-Reply-To: <YBfiIwdVP1dXg7Yt@myrica>

Hi Jean,

On 2/1/21 12:12 PM, Jean-Philippe Brucker wrote:
> On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
>> Hi Jean,
>>
>> Some rather minor comments§questions below that may not justify a respin.
>>
>> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
>>> -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
>>> +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
>>>  {
>>> -	return false;
>>> +	/* We're not keeping track of SIDs in fault events */
>> shall we? [*] below
> 
> That would require storing the incoming SID into the iommu_fault_event
> struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
> don't think it's needed for existing devices.
OK
> 
>>> +	if (master->num_streams != 1)
>>> +		return false;
> [...]
>>> +static int arm_smmu_page_response(struct device *dev,
>>> +				  struct iommu_fault_event *unused,
>>> +				  struct iommu_page_response *resp)
>>> +{
>>> +	struct arm_smmu_cmdq_ent cmd = {0};
>>> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
>>> +	int sid = master->streams[0].id;
>> [*]
>>> +
>>> +	if (master->stall_enabled) {
>>> +		cmd.opcode		= CMDQ_OP_RESUME;
>>> +		cmd.resume.sid		= sid;
>>> +		cmd.resume.stag		= resp->grpid;
>>> +		switch (resp->code) {
>>> +		case IOMMU_PAGE_RESP_INVALID:
>> add fallthrough?
> 
> I think fallthrough is mainly useful to tell reader and compiler that a
> break was omitted on purpose. When two cases are stuck together the intent
> to merge the flow is clear enough in my opinion. GCC's
> -Wimplicit-fallthrough doesn't warn in this case.
OK
> 
>>> +		case IOMMU_PAGE_RESP_FAILURE:
>>> +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
>>> +			break;
> [...]
>>> +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
>>> +{
>>> +	int ret;
>>> +	u32 reason;
>>> +	u32 perm = 0;
>>> +	struct arm_smmu_master *master;
>>> +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
>>> +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
>>> +	struct iommu_fault_event fault_evt = { };
>>> +	struct iommu_fault *flt = &fault_evt.fault;
>>> +
>>> +	/* Stage-2 is always pinned at the moment */
>>> +	if (evt[1] & EVTQ_1_S2)
>>> +		return -EFAULT;
>>> +
>>> +	master = arm_smmu_find_master(smmu, sid);
>>> +	if (!master)
>>> +		return -EINVAL;
>>> +
>>> +	if (evt[1] & EVTQ_1_RnW)
>>> +		perm |= IOMMU_FAULT_PERM_READ;
>>> +	else
>>> +		perm |= IOMMU_FAULT_PERM_WRITE;
>>> +
>>> +	if (evt[1] & EVTQ_1_InD)
>>> +		perm |= IOMMU_FAULT_PERM_EXEC;
>>> +
>>> +	if (evt[1] & EVTQ_1_PnU)
>>> +		perm |= IOMMU_FAULT_PERM_PRIV;
>>> +
>>> +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
>>> +	case EVT_ID_TRANSLATION_FAULT:
>>> +	case EVT_ID_ADDR_SIZE_FAULT:
>>> +	case EVT_ID_ACCESS_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
>> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
>> /* access flag check failed */"
> 
> Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
> corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?
yes it dies
> 
> By the way the wording on those two fault reasons, "access flag" and
> "stage", seems arch-specific - x86 names are "accessed flag" and "level".
> 
>>> +		break;
>>> +	case EVT_ID_PERMISSION_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PERMISSION;
>>> +		break;
>>> +	default:
>>> +		return -EOPNOTSUPP;
>>> +	}
>>> +
>>> +	if (evt[1] & EVTQ_1_STALL) {
>>> +		flt->type = IOMMU_FAULT_PAGE_REQ;
>>> +		flt->prm = (struct iommu_fault_page_request) {
>>> +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
>>> +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +		};
>>> +
>>> +		if (ssid_valid) {
>>> +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
>>> +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
>>> +		}
>>> +	} else {
>>> +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
>>> +		flt->event = (struct iommu_fault_unrecoverable) {
>>> +			.reason = reason,
>>> +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
>>> +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
>> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
>> unrecoverable faults feature the IPA field which is UNKNOWN for S1
>> translations. fetch_addr rather was
>> corresponding to WALK_EABT.Fetch_addr to me.
> 
> Right I should drop the IPA part entirely, since we don't report S2 faults
> in this patch.
OK

But as I mentioned this can be fixed separately if you don't have other
comments on this version.

Thanks

Eric
> 
> Thanks,
> Jean
> 
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
>>> +		};
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com,
	lorenzo.pieralisi@arm.com, linux-acpi@vger.kernel.org,
	robin.murphy@arm.com, joro@8bytes.org,
	Jonathan.Cameron@huawei.com, rjw@rjwysocki.net,
	robh+dt@kernel.org, sudeep.holla@arm.com, vivek.gautam@arm.com,
	iommu@lists.linux-foundation.org, jacob.jun.pan@linux.intel.com,
	shameerali.kolothum.thodi@huawei.com,
	linux-accelerators@lists.ozlabs.org, guohanjun@huawei.com,
	zhangfei.gao@linaro.org, baolu.lu@linux.intel.com,
	will@kernel.org, linux-arm-kernel@lists.infradead.org,
	lenb@kernel.org
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 14:16:16 +0100	[thread overview]
Message-ID: <47a65f65-26cb-de27-049a-48f2d083964a@redhat.com> (raw)
In-Reply-To: <YBfiIwdVP1dXg7Yt@myrica>

Hi Jean,

On 2/1/21 12:12 PM, Jean-Philippe Brucker wrote:
> On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
>> Hi Jean,
>>
>> Some rather minor comments§questions below that may not justify a respin.
>>
>> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
>>> -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
>>> +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
>>>  {
>>> -	return false;
>>> +	/* We're not keeping track of SIDs in fault events */
>> shall we? [*] below
> 
> That would require storing the incoming SID into the iommu_fault_event
> struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
> don't think it's needed for existing devices.
OK
> 
>>> +	if (master->num_streams != 1)
>>> +		return false;
> [...]
>>> +static int arm_smmu_page_response(struct device *dev,
>>> +				  struct iommu_fault_event *unused,
>>> +				  struct iommu_page_response *resp)
>>> +{
>>> +	struct arm_smmu_cmdq_ent cmd = {0};
>>> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
>>> +	int sid = master->streams[0].id;
>> [*]
>>> +
>>> +	if (master->stall_enabled) {
>>> +		cmd.opcode		= CMDQ_OP_RESUME;
>>> +		cmd.resume.sid		= sid;
>>> +		cmd.resume.stag		= resp->grpid;
>>> +		switch (resp->code) {
>>> +		case IOMMU_PAGE_RESP_INVALID:
>> add fallthrough?
> 
> I think fallthrough is mainly useful to tell reader and compiler that a
> break was omitted on purpose. When two cases are stuck together the intent
> to merge the flow is clear enough in my opinion. GCC's
> -Wimplicit-fallthrough doesn't warn in this case.
OK
> 
>>> +		case IOMMU_PAGE_RESP_FAILURE:
>>> +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
>>> +			break;
> [...]
>>> +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
>>> +{
>>> +	int ret;
>>> +	u32 reason;
>>> +	u32 perm = 0;
>>> +	struct arm_smmu_master *master;
>>> +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
>>> +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
>>> +	struct iommu_fault_event fault_evt = { };
>>> +	struct iommu_fault *flt = &fault_evt.fault;
>>> +
>>> +	/* Stage-2 is always pinned at the moment */
>>> +	if (evt[1] & EVTQ_1_S2)
>>> +		return -EFAULT;
>>> +
>>> +	master = arm_smmu_find_master(smmu, sid);
>>> +	if (!master)
>>> +		return -EINVAL;
>>> +
>>> +	if (evt[1] & EVTQ_1_RnW)
>>> +		perm |= IOMMU_FAULT_PERM_READ;
>>> +	else
>>> +		perm |= IOMMU_FAULT_PERM_WRITE;
>>> +
>>> +	if (evt[1] & EVTQ_1_InD)
>>> +		perm |= IOMMU_FAULT_PERM_EXEC;
>>> +
>>> +	if (evt[1] & EVTQ_1_PnU)
>>> +		perm |= IOMMU_FAULT_PERM_PRIV;
>>> +
>>> +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
>>> +	case EVT_ID_TRANSLATION_FAULT:
>>> +	case EVT_ID_ADDR_SIZE_FAULT:
>>> +	case EVT_ID_ACCESS_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
>> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
>> /* access flag check failed */"
> 
> Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
> corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?
yes it dies
> 
> By the way the wording on those two fault reasons, "access flag" and
> "stage", seems arch-specific - x86 names are "accessed flag" and "level".
> 
>>> +		break;
>>> +	case EVT_ID_PERMISSION_FAULT:
>>> +		reason = IOMMU_FAULT_REASON_PERMISSION;
>>> +		break;
>>> +	default:
>>> +		return -EOPNOTSUPP;
>>> +	}
>>> +
>>> +	if (evt[1] & EVTQ_1_STALL) {
>>> +		flt->type = IOMMU_FAULT_PAGE_REQ;
>>> +		flt->prm = (struct iommu_fault_page_request) {
>>> +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
>>> +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +		};
>>> +
>>> +		if (ssid_valid) {
>>> +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
>>> +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
>>> +		}
>>> +	} else {
>>> +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
>>> +		flt->event = (struct iommu_fault_unrecoverable) {
>>> +			.reason = reason,
>>> +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
>>> +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
>> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
>> unrecoverable faults feature the IPA field which is UNKNOWN for S1
>> translations. fetch_addr rather was
>> corresponding to WALK_EABT.Fetch_addr to me.
> 
> Right I should drop the IPA part entirely, since we don't report S2 faults
> in this patch.
OK

But as I mentioned this can be fixed separately if you don't have other
comments on this version.

Thanks

Eric
> 
> Thanks,
> Jean
> 
>>> +			.perm = perm,
>>> +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>> +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
>>> +		};
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


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

  reply	other threads:[~2021-02-01 13:19 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 15:43 [PATCH v12 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-01-27 15:43 ` Jean-Philippe Brucker
2021-01-27 15:43 ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 01/10] iommu: Fix comment for struct iommu_fwspec Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:30   ` Auger Eric
2021-02-01  7:30     ` Auger Eric
2021-02-01  7:30     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:35   ` Auger Eric
2021-02-01  7:35     ` Auger Eric
2021-02-01  7:35     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-31 18:29   ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-02-02  5:51   ` Shenming Lu
2021-02-02  5:51     ` Shenming Lu
2021-02-02  5:51     ` Shenming Lu
2021-01-27 15:43 ` [PATCH v12 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:28   ` Auger Eric
2021-02-01  7:28     ` Auger Eric
2021-02-01  7:28     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-31 18:29   ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-02-01 11:12     ` Jean-Philippe Brucker
2021-02-01 11:12       ` Jean-Philippe Brucker
2021-02-01 11:12       ` Jean-Philippe Brucker
2021-02-01 13:16       ` Auger Eric [this message]
2021-02-01 13:16         ` Auger Eric
2021-02-01 13:16         ` Auger Eric
2021-02-01 15:19         ` Jean-Philippe Brucker
2021-02-01 15:19           ` Jean-Philippe Brucker
2021-02-01 15:19           ` Jean-Philippe Brucker
2021-02-01  1:18   ` Zhou Wang
2021-02-01  1:18     ` Zhou Wang
2021-02-01  1:18     ` Zhou Wang
2021-02-01 11:14     ` Jean-Philippe Brucker
2021-02-01 11:14       ` Jean-Philippe Brucker
2021-02-01 11:14       ` Jean-Philippe Brucker
2021-02-01 12:53       ` Zhou Wang
2021-02-01 12:53         ` Zhou Wang
2021-02-01 12:53         ` Zhou Wang
2021-02-26  9:43       ` Zhou Wang
2021-02-26  9:43         ` Zhou Wang
2021-02-26  9:43         ` Zhou Wang
2021-02-26 16:29         ` Jean-Philippe Brucker
2021-02-26 16:29           ` Jean-Philippe Brucker
2021-02-26 16:29           ` Jean-Philippe Brucker
2021-02-27  3:40           ` Zhou Wang
2021-02-27  3:40             ` Zhou Wang
2021-02-27  3:40             ` Zhou Wang

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=47a65f65-26cb-de27-049a-48f2d083964a@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=guohanjun@huawei.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=lenb@kernel.org \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=sudeep.holla@arm.com \
    --cc=vivek.gautam@arm.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.org \
    /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.