xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
	ian.campbell@citrix.com, tim@xen.org
Subject: Re: [RFC 11/19] xen/passthrough: Call arch_iommu_domain_destroy before calling iommu_teardown
Date: Tue, 17 Jun 2014 13:38:18 +0100	[thread overview]
Message-ID: <53A036BA.9090905@linaro.org> (raw)
In-Reply-To: <53A02685020000780001AEBF@mail.emea.novell.com>

On 06/17/2014 10:29 AM, Jan Beulich wrote:
>>>> On 17.06.14 at 11:18, <julien.grall@linaro.org> wrote:
>> On 17/06/14 09:07, Jan Beulich wrote:
>>>>>> On 16.06.14 at 18:17, <julien.grall@linaro.org> 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.

>>> And it's rather hard to properly decide with the series here
>>> depending on two other series, i.e. there not being a
>>> arch_iommu_domain_destroy() at all in current staging.
>>
>> Are you sure? The other series doesn't deal with the IOMMU stuff. This 
>> change has been pushed upstream a month ago (see commit 4905b35c " 
>> iommu: introduce arch specific code").
> 
> Oops, indeed - I'm sorry, I looked at a stale branch. Looking at the
> correct code I still think the current order is the correct one, and if
> you need to take extra steps you ought to do so from the .teardown
> hook.

I though about implement it in .teardown, but it results to non-obvious
code.

I could call iommu_dt_domain_destroy in .teardown, that will mean to
call "arch dt" code in the SMMU drivers which I think break the design.
I would prefer call it the arch specific function. Do you mind if I add
a new function called arch_iommu_reassign_devices? This function will
reassign every devices of a given domain to the hardware domain.

The iommmu_domain_destroy will look like:

void iommu_domain_destroy(struct domain *d)
{
	if ( !iommu_enabled )
		return;

	arch_iommu_reassign_devices(d);
	if ( need_iommu(d) )
	  iommu_teardown(d);
	arch_iommu_domain_destroy(d);
}

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-06-17 12:38 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-16 16:17 [RFC 00/19] xe/arm: Add support for non-pci passthrough Julien Grall
2014-06-16 16:17 ` [RFC 01/19] xen/arm: guest_physmap_remove_page: Print a warning if we fail to unmap the page Julien Grall
2014-06-18 15:03   ` Stefano Stabellini
2014-07-03 10:52   ` Ian Campbell
2014-07-03 11:17     ` Julien Grall
2014-06-16 16:17 ` [RFC 02/19] xen: guestcopy: Provide an helper to copy string from guest Julien Grall
2014-06-17  8:01   ` Jan Beulich
2014-06-17  9:09     ` Julien Grall
2014-06-17  9:17       ` Jan Beulich
2014-06-17  9:23         ` Julien Grall
2014-06-17 22:43           ` Daniel De Graaf
2014-06-18 11:59             ` Jan Beulich
2014-06-18 12:22               ` Julien Grall
2014-06-18 12:49                 ` Jan Beulich
2014-06-18 12:53                   ` Julien Grall
2014-06-18 13:01                     ` Jan Beulich
2014-06-24 14:58                       ` Julien Grall
2014-06-16 16:17 ` [RFC 03/19] xen/arm: follow-up to allow DOM0 manage IRQ and MMIO Julien Grall
2014-06-18 20:21   ` Stefano Stabellini
2014-06-18 20:32     ` Julien Grall
2014-07-03 11:02       ` Ian Campbell
2014-07-03 11:23         ` Julien Grall
2014-07-03 12:12           ` Ian Campbell
2014-06-16 16:17 ` [RFC 04/19] xen/arm: route_irq_to_guest: Check validity of the IRQ Julien Grall
2014-06-18 18:52   ` Stefano Stabellini
2014-06-18 19:03     ` Julien Grall
2014-07-03 11:04   ` Ian Campbell
2014-07-03 11:47     ` Julien Grall
2014-06-16 16:17 ` [RFC 05/19] xen/arm: Release IRQ routed to a domain when it's destroying Julien Grall
2014-06-18 18:08   ` Stefano Stabellini
2014-06-18 18:26     ` Julien Grall
2014-06-18 18:48       ` Stefano Stabellini
2014-06-18 18:54         ` Julien Grall
2014-06-18 19:06           ` Stefano Stabellini
2014-06-18 19:09             ` Julien Grall
2014-06-16 16:17 ` [RFC 06/19] xen/arm: Implement hypercall PHYSDEVOP_map_pirq Julien Grall
2014-06-18 19:24   ` Stefano Stabellini
2014-06-19 11:39     ` Julien Grall
2014-06-19 12:29       ` Stefano Stabellini
2014-07-03 11:27         ` Ian Campbell
2014-07-03 12:02           ` Julien Grall
2014-07-03 12:53             ` Ian Campbell
2014-07-15 13:01               ` Julien Grall
2014-07-15 13:03                 ` Ian Campbell
2014-08-18 19:20                   ` Andrii Tseglytskyi
2014-08-18 21:55                     ` Julien Grall
2014-08-19  9:11                       ` Andrii Tseglytskyi
2014-08-19 14:24                         ` Julien Grall
2014-06-16 16:17 ` [RFC 07/19] xen/dts: Use unsigned int for MMIO and IRQ index Julien Grall
2014-06-18 18:54   ` Stefano Stabellini
2014-06-19 11:42     ` Julien Grall
2014-06-16 16:17 ` [RFC 08/19] xen/dts: Provide an helper to get a DT node from a path provided by a guest Julien Grall
2014-07-03 11:30   ` Ian Campbell
2014-07-03 11:49     ` Julien Grall
2014-07-03 12:13       ` Ian Campbell
2014-07-03 12:22         ` Julien Grall
2014-06-16 16:17 ` [RFC 09/19] xen/dts: Add hypercalls to retrieve device node information Julien Grall
2014-06-18 19:38   ` Stefano Stabellini
2014-06-19 11:58     ` Julien Grall
2014-06-19 12:21       ` Stefano Stabellini
2014-06-19 12:25         ` Julien Grall
2014-07-03 11:40           ` Ian Campbell
2014-06-24  8:46       ` Christoffer Dall
2014-07-03 11:34       ` Ian Campbell
2014-07-03 11:33   ` Ian Campbell
2014-07-03 11:51     ` Julien Grall
2014-07-03 12:13       ` Ian Campbell
2014-06-16 16:17 ` [RFC 10/19] xen/passthrough: Introduce iommu_buildup Julien Grall
2014-07-03 11:45   ` Ian Campbell
2014-07-03 11:55     ` Julien Grall
2014-06-16 16:17 ` [RFC 11/19] xen/passthrough: Call arch_iommu_domain_destroy before calling iommu_teardown Julien Grall
2014-06-17  8:07   ` Jan Beulich
2014-06-17  9:18     ` Julien Grall
2014-06-17  9:29       ` Jan Beulich
2014-06-17 12:38         ` Julien Grall [this message]
2014-06-17 13:04           ` Jan Beulich
2014-06-18 12:24             ` Julien Grall
2014-06-18 12:50               ` Jan Beulich
2014-06-16 16:17 ` [RFC 12/19] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody Julien Grall
2014-06-18 19:28   ` Stefano Stabellini
2014-07-03 11:48   ` Ian Campbell
2014-07-03 12:07     ` Julien Grall
2014-07-03 12:53       ` Ian Campbell
2014-07-03 13:01         ` Julien Grall
2014-07-03 13:42           ` Ian Campbell
2014-07-03 13:51             ` Julien Grall
2014-07-03 14:04               ` Ian Campbell
2014-07-03 14:09                 ` Julien Grall
2014-06-16 16:18 ` [RFC 13/19] xen/iommu: arm: Wire iommu DOMCTL for ARM Julien Grall
2014-06-17  8:24   ` Jan Beulich
2014-06-17 13:05     ` Julien Grall
2014-06-16 16:18 ` [RFC 14/19] xen/passthrough: dt: Add new domctl XEN_DOMCTL_assign_dt_device Julien Grall
2014-06-17  8:34   ` Jan Beulich
2014-06-17 13:23     ` Julien Grall
2014-06-17 13:30       ` Jan Beulich
2014-06-17 13:48         ` Julien Grall
2014-06-17 13:55           ` Jan Beulich
2014-07-03 11:54             ` Ian Campbell
2014-06-16 16:18 ` [RFC 15/19] xen/arm: Reserve region in guest memory for device passthrough Julien Grall
2014-06-18 15:12   ` Stefano Stabellini
2014-06-18 15:23     ` Julien Grall
2014-06-18 15:26       ` Ian Campbell
2014-06-18 17:48         ` Stefano Stabellini
2014-06-18 17:54           ` Julien Grall
2014-06-18 18:14             ` Stefano Stabellini
2014-06-18 18:33               ` Julien Grall
2014-06-18 18:55                 ` Stefano Stabellini
2014-07-03 11:56                 ` Ian Campbell
2014-06-16 16:18 ` [RFC 16/19] libxl/arm: Introduce DT_IRQ_TYPE_* Julien Grall
2014-07-03 11:56   ` Ian Campbell
2014-06-16 16:18 ` [RFC 17/19] libxl/arm: Rename set_interrupt_ppi to set_interrupt and handle SPIs Julien Grall
2014-07-03 11:58   ` Ian Campbell
2014-07-03 12:04     ` Julien Grall
2014-07-03 14:04       ` Ian Campbell
2014-06-16 16:18 ` [RFC 18/19] libxl: Add support for non-PCI passthrough Julien Grall
2014-06-16 17:19   ` Wei Liu
2014-06-18 12:26     ` Julien Grall
2014-06-16 16:18 ` [RFC 19/19] xl: Add new option dtdev Julien Grall
2014-06-16 17:19   ` Wei Liu
2014-06-18 13:40     ` Julien Grall
2014-06-18 13:43       ` Wei Liu
2014-06-18 13:46         ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A036BA.9090905@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).