On Tue, Sep 27, 2011 at 12:59 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Mon, Sep 26, 2011 at 5:48 PM, KyongHo Cho <pullip.cho@xxxxxxxxxxx> wrote: >> I am sorry but I still think that >> installing default fault handler is quite simple and straightforward. > > ... and abusing the IOMMU API. > > Please don't do that. Interfaces are written for specific goals, and > this one was added for IOMMU users, not drivers. Just like all the > other map/unmap/attach/... APIs. > > By using this from the IOMMU driver itself, you are adding burden on > future development and evolution of this API. As use cases > materialize, we will have to change it to support them, while > considering existing use cases. Using this API inappropriately will > make our life harder later on. I didn't think about this case. It can be a problem if IOMMU driver is dependent upon the change of IOMMU API as you told above. > > Moreover, I'm really not sure how exactly are you going to use this. > > If you're having an IOMMU user which installs its own fault handler, > then this is all moot since the default behavior you provide here will > be overridden. Yes, this is what I really want. I wanted the IOMMU driver to provide default fault handler to its users that does not provide fault handler for debugging purpose. If a user want to handle MMU fault, IOMMU driver welcomes to overwrite the existing 'default' fault handler. > If you're not having an IOMMU user which installs its own fault > handler, then just provide the default behavior in your irq handler, > regardless whether you report the fault to the IOMMU core or not. Or > only when it fails. and yes, we can provide different error values for > different scenarios. it's not rocket science :). > > Really, there's a myriad of ways to do this right. Please explain your > exact settings/use-case and I'll gladly help you find a clean > solution. > Thank you. As I explained before, MMU fault in our system is abnormal and the situation cannot be recovered because mapping information is set up completely before System MMU starts address translation with the mapping information. However we have to capture the MMU fault for debugging purpose. That's why our fault handler just prints debugging messages and generates kernel OOPS A user of IOMMU may handle MMU faults due to the following reason: - Its IOMMU sees the virtual address space of the user process (IOMMU refers the page table of CPU) and virtual memory region allocated by userspace is not filled with physical memory. Device driver which is user of IOMMU does not call get_user_pages() for the region but handle page fault generated by IOMMU. - A device driver working in the Monitor mode in ARM processors need to protect a memory region from access in the Normal mode. If it happens, the device driver must catch the situation, stop the current operation and inform the problem to the userspace. For the above reasons, some user of IOMMU may override the default fault handler. > Thanks, > Ohad. Thanks and regards, Cho KyongHo. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |