From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH 01/37] iommu: Introduce Shared Virtual Addressing API Date: Wed, 28 Feb 2018 16:20:45 +0000 Message-ID: References: <20180212183352.22730-1-jean-philippe.brucker@arm.com> <20180212183352.22730-2-jean-philippe.brucker@arm.com> <0b579768-3090-dd50-58b1-3385be92ef21@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Tian, Kevin" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" Cc: Mark Rutland , "bharatku-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org" , "Raj, Ashok" , "rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org" , Catalin Marinas , "xuzaibo-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , "ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Will Deacon , "okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , Sudeep Holla , "rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org" , "dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" , "christian.koenig-5C7GfCeVMHo@public.gmane.org" , "lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" List-Id: devicetree@vger.kernel.org On 27/02/18 06:21, Tian, Kevin wrote: [...] >> Technically nothing prevents it, but now the resv problem discussed on >> patch 2/37 stands out. For example on x86 you'd probably need to carve >> the >> IOAPIC MSI range out of the process address space. On Arm you'd need to >> create a write-only mapping for MSIs (IOMMU translates it to the IRQ chip >> address, but thankfully accessing the doorbell from CPU side doesn't >> trigger an MSI.) > > so if overlap already exists when binding a process address space > (since binding may happen much later than creating the process), > I assume the call will simply fail since carve out at this point is not > possible? Yes in this case I think it's safer to abort the bind() call Thanks, Jean