On Mon, Feb 24, 2025 at 01:56:46PM -0800, Nicolin Chen wrote:
On Mon, Feb 24, 2025 at 09:35:14PM +0000, Pranjal Shrivastava wrote:
On Sat, Feb 22, 2025 at 07:54:10AM -0800, Nicolin Chen wrote:
+int arm_vmaster_report_event(struct arm_smmu_vmaster *vmaster, u64 *evt) +{
- struct iommu_vevent_arm_smmuv3 vevt;
- int i;
- lockdep_assert_held(&vmaster->vsmmu->smmu->streams_mutex);
- vevt.evt[0] = cpu_to_le64((evt[0] & ~EVTQ_0_SID) |
FIELD_PREP(EVTQ_0_SID, vmaster->vsid));
- for (i = 1; i < EVTQ_ENT_DWORDS; i++)
vevt.evt[i] = cpu_to_le64(evt[i]);
Just thinking out loud here: I understand the goal here is to "emulate" an IOMMU. But I'm just wondering if we could report struct events instead of the raw event?
For example, can't we have something like arm_smmu_event here with the sid changed to vsid?
Are we taking the raw event since we want to keep the `u64 event_data[]` field within `struct iommufd_vevent` generic to all architectures?
The ABIs for vSMMU are defined in the HW languange, e.g. cmd, ste. Thus, here evt in raw too.
Ack. Makes sense.
- ret = iommu_report_device_fault(master->dev, &fault_evt);
- if (event->stall) {
ret = iommu_report_device_fault(master->dev, &fault_evt);
- } else {
if (master->vmaster && !event->s2)
ret = arm_vmaster_report_event(master->vmaster, evt);
else
ret = -EFAULT; /* Unhandled events should be pinned */
- }
Nit: I don't see the `arm_smmu_handle_event` being called elsewhere, is there a reason to return -EFAULT instead of -EOPNOTSUPP here?
I think the current behavior here is to return -EOPNOTSUPP if (!event->stall). Whereas, what we're doing here is: if (event->stall) { ... /* do legacy stuff */ ... }
else { if (master->vmaster && !event->s2) arm_vmaster_report_event(vmaster, evt); else ret = -EFAULT }
mutex_unlock(&smmu->streams_mutex); return ret;
Thus, we end up returning -EFAULT instead of -EOPNOTSUPP in case event->stall == false. I agree that we aren't really checking the return value in the evtq_thread handler, but I'm wondering if we should ensure that we end up retaining the same behaviour as we have right now?
Oh, it looks like -EOPNOTSUPP should be returned here. Will fix.
With the fix to return `-EOPNOTSUPP`:
Reviewed-by: Pranjal Shrivastava praan@google.com
Thanks, Praan