Messages in this thread | | | Subject | Re: [PATCH 2/4] iommu: Introduce device fault data | From | Jean-Philippe Brucker <> | Date | Fri, 24 May 2019 17:14:30 +0100 |
| |
On 24/05/2019 14:49, Jacob Pan wrote: > On Thu, 23 May 2019 19:43:46 +0100 > Robin Murphy <robin.murphy@arm.com> wrote: >>> +/** >>> + * struct iommu_fault_event - Generic fault event >>> + * >>> + * Can represent recoverable faults such as a page requests or >>> + * unrecoverable faults such as DMA or IRQ remapping faults. >>> + * >>> + * @fault: fault descriptor >>> + * @iommu_private: used by the IOMMU driver for storing >>> fault-specific >>> + * data. Users should not modify this field before >>> + * sending the fault response. >> >> Sorry if I'm a bit late to the party, but given that description, if >> users aren't allowed to touch this then why expose it to them at all? >> I.e. why not have iommu_report_device_fault() pass just the fault >> itself to the fault handler: >> >> ret = fparam->handler(&evt->fault, fparam->data); >> >> and let the IOMMU core/drivers decapsulate it again later if need be. >> AFAICS drivers could also just embed the entire generic event in >> their own private structure anyway, just as we do for domains. >> > I can't remember all the discussion history but I think iommu_private > is used similarly to the page request private data (device private).
Hm yes, we already have iommu_fault_page_request::private_data for that. I think I used to stash flags in iommu_private (is_stall and needs_pasid), so that the SMMUv3 driver doesn't need to go fetch them from the device structure, but I removed them. If VT-d doesn't need iommu_private either, maybe we can remove it entirely?
In any case I agree that device drivers should only need to know about evt->fault.
> We > need to inject the data to the guest and the guest will send the > unmodified data back along with response.
By the way, does private_data need to go back through the iommu_page_response() path? The current series doesn't do that.
> The private data can be used > to tag internal device/iommu context.
> I think we can do the way you said by keeping them within iommu core > and recover it based on the response but that would require tracking > each fault report, right?
That's already the case: we decided in thread [1] to track recoverable faults in the IOMMU core, in order to check that the response is sane and to set a quota and/or timeout. (I didn't include your timeout patches here because I think they need a little more work. They are on my sva/api branch.)
I already dropped iommu_private from the iommu_page_response structure. In patch 4 iommu_page_response() retrieves the fault event and pass the corresponding iommu_private back to the IOMMU driver.
[1] https://lore.kernel.org/lkml/20171206112521.1edf8e9b@jacob-builder/
Thanks, Jean
> > If we pass on the private data, we only need to check if the response > belong to the device but not exact match of a specific fault since the > damage is contained in the assigned device. In case of injection > fault into the guest, the response will come asynchronously after the > handler completes.
| |