All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: peter.maydell@linaro.org, kevin.tian@intel.com,
	tnowicki@marvell.com, mst@redhat.com, quintela@redhat.com,
	qemu-devel@nongnu.org, dgilbert@redhat.com,
	bharatb.linux@gmail.com, qemu-arm@nongnu.org,
	jean-philippe@linaro.org, eric.auger.pro@gmail.com
Subject: Re: [PATCH v13 03/10] virtio-iommu: Implement attach/detach command
Date: Mon, 3 Feb 2020 18:46:36 +0100	[thread overview]
Message-ID: <5289913a-43fc-aaae-5b82-151922de93bf@redhat.com> (raw)
In-Reply-To: <20200203151917.GD155875@xz-x1>

Hi Peter,

On 2/3/20 4:19 PM, Peter Xu wrote:
> On Mon, Feb 03, 2020 at 03:59:00PM +0100, Auger Eric wrote:
> 
> [...]
> 
>>>> +static void virtio_iommu_detach_endpoint_from_domain(VirtIOIOMMUEndpoint *ep)
>>>> +{
>>>> +    QLIST_REMOVE(ep, next);
>>>> +    g_tree_unref(ep->domain->mappings);
>>>
>>> Here domain->mapping is unreferenced for each endpoint, while at [1]
>>> below you only reference the domain->mappings if it's the first
>>> endpoint.  Is that problematic?
>> in [1] I take a ref to the domain->mappings if it is *not* the 1st
>> endpoint. This aims at deleting the mappings gtree when the last EP is
>> detached from the domain.
>>
>> This fixes the issue reported by Jean in:
>> https://patchwork.kernel.org/patch/11258267/#23046313
> 
> Ah OK. :)
> 
> However this is tricky.  How about do explicit g_tree_destroy() in
> virtio_iommu_detach() when it's the last endpoint?  I see that you
> have:
> 
>     /*
>      * when the last EP is detached, simply remove the domain for
>      * the domain list and destroy it. Note its mappings were already
>      * freed by the ref count mechanism. Next operation involving
>      * the same domain id will re-create one domain object.
>      */
>     if (QLIST_EMPTY(&domain->endpoint_list)) {
>         g_tree_remove(s->domains, GUINT_TO_POINTER(domain->id));
>     }
> 
> Then it becomes:
> 
>     if (QLIST_EMPTY(&domain->endpoint_list)) {
>         g_tree_destroy(domain->mappings);
>         g_tree_remove(s->domains, GUINT_TO_POINTER(domain->id));
>     }
> 
> And also remove the trick in attach() so you take the domain ref
> unconditionally.  Would that work?
Yes I think so. On the other hand this ref counting mechanism is also
made for that purpose of destroying objects without being forced to
explicitly call the destroy function.

Thanks

Eric
> 
> Thanks,
> 



  reply	other threads:[~2020-02-03 17:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-25 17:19 [PATCH v13 00/10] VIRTIO-IOMMU device Eric Auger
2020-01-25 17:19 ` [PATCH v13 01/10] virtio-iommu: Add skeleton Eric Auger
2020-01-25 17:19 ` [PATCH v13 02/10] virtio-iommu: Decode the command payload Eric Auger
2020-01-25 17:19 ` [PATCH v13 03/10] virtio-iommu: Implement attach/detach command Eric Auger
2020-02-03 13:49   ` Peter Xu
2020-02-03 14:59     ` Auger Eric
2020-02-03 15:19       ` Peter Xu
2020-02-03 17:46         ` Auger Eric [this message]
2020-02-03 18:19           ` Peter Xu
2020-02-04 12:26             ` Auger Eric
2020-01-25 17:19 ` [PATCH v13 04/10] virtio-iommu: Implement map/unmap Eric Auger
2020-01-25 17:19 ` [PATCH v13 05/10] virtio-iommu: Implement translate Eric Auger
2020-01-25 17:19 ` [PATCH v13 06/10] virtio-iommu: Implement fault reporting Eric Auger
2020-02-03 13:55   ` Peter Xu
2020-02-03 15:01     ` Auger Eric
2020-01-25 17:19 ` [PATCH v13 07/10] virtio-iommu-pci: Add virtio iommu pci support Eric Auger
2020-02-03 13:03   ` Michael S. Tsirkin
2020-02-03 13:20     ` Auger Eric
2020-02-03 13:28       ` Michael S. Tsirkin
2020-02-03 13:38         ` Auger Eric
2020-02-03 13:46           ` Michael S. Tsirkin
2020-02-03 13:52             ` Auger Eric
2020-01-25 17:19 ` [PATCH v13 08/10] hw/arm/virt: Add the virtio-iommu device tree mappings Eric Auger
2020-01-25 17:19 ` [PATCH v13 09/10] virtio-iommu: Support migration Eric Auger
2020-01-25 17:19 ` [PATCH v13 10/10] tests: Add virtio-iommu test Eric Auger
2020-02-03 12:58 ` [PATCH v13 00/10] VIRTIO-IOMMU device Auger Eric
2020-02-03 13:49   ` Peter Xu
2020-02-03 13:51     ` Auger Eric

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=5289913a-43fc-aaae-5b82-151922de93bf@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=bharatb.linux@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=jean-philippe@linaro.org \
    --cc=kevin.tian@intel.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=tnowicki@marvell.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.