From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 11/19] xen/passthrough: Call arch_iommu_domain_destroy before calling iommu_teardown Date: Wed, 18 Jun 2014 13:24:36 +0100 Message-ID: <53A18504.9000800@linaro.org> References: <1402935486-29136-1-git-send-email-julien.grall@linaro.org> <1402935486-29136-12-git-send-email-julien.grall@linaro.org> <53A01376020000780001AE02@mail.emea.novell.com> <53A007E7.4050407@linaro.org> <53A02685020000780001AEBF@mail.emea.novell.com> <53A036BA.9090905@linaro.org> <53A058EB020000780001B0E3@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WxEuu-0005ZY-Bt for xen-devel@lists.xenproject.org; Wed, 18 Jun 2014 12:24:40 +0000 Received: by mail-wi0-f177.google.com with SMTP id r20so1021750wiv.10 for ; Wed, 18 Jun 2014 05:24:38 -0700 (PDT) In-Reply-To: <53A058EB020000780001B0E3@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, ian.campbell@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 06/17/2014 02:04 PM, Jan Beulich wrote: >>>> On 17.06.14 at 14:38, wrote: >> On 06/17/2014 10:29 AM, Jan Beulich wrote: >>>>>> On 17.06.14 at 11:18, wrote: >>>> On 17/06/14 09:07, Jan Beulich wrote: >>>>>>>> On 16.06.14 at 18:17, wrote: >>>>>> --- a/xen/drivers/passthrough/iommu.c >>>>>> +++ b/xen/drivers/passthrough/iommu.c >>>>>> @@ -219,10 +219,10 @@ void iommu_domain_destroy(struct domain *d) >>>>>> if ( !iommu_enabled || !hd->platform_ops ) >>>>>> return; >>>>>> >>>>>> + arch_iommu_domain_destroy(d); >>>>>> + >>>>>> if ( need_iommu(d) ) >>>>>> iommu_teardown(d); >>>>>> - >>>>>> - arch_iommu_domain_destroy(d); >>>>> >>>>> At the first glance this doesn't look right, including the explanation >>>>> you gave (why would devices still be assigned to a guest at this >>>>> point). >>>> >>>> Because the toolstack may forget to deassign a device. How do you handle >>>> this case in x86? In the SMMU case, this will mean a memory leak and >>>> misconfiguration of the registers. >>> >>> Proper tool stack behavior is required (and not just here). >> >> I think this is important to handle toolstack failure (such as crash) >> just in case. Hence it doesn't add much code for this purpose. > > If you think this is necessary, then there's no reason to make this > ARM-specific (which in turn would eliminate the need for this to sit > in an arch hook). We will have to do DT/PCI specific as I don't use the same way to know which device is assigned to which guest. I won't be able to write (or at least test) the piece of code for the PCI part as my ARM board doesn't support PCI and I don't have a Xen setup for x86. Regards, -- Julien Grall