qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: "eduardo@habkost.net" <eduardo@habkost.net>,
	Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	John Johnson <john.g.johnson@oracle.com>,
	Jag Raman <jag.raman@oracle.com>,
	"bleal@redhat.com" <bleal@redhat.com>,
	"john.levon@nutanix.com" <john.levon@nutanix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"quintela@redhat.com" <quintela@redhat.com>,
	"f4bug@amsat.org" <f4bug@amsat.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Kanth Ghatraju <kanth.ghatraju@oracle.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"thanos.makatos@nutanix.com" <thanos.makatos@nutanix.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"eblake@redhat.com" <eblake@redhat.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [PATCH v7 12/17] vfio-user: IOMMU support for remote device
Date: Wed, 30 Mar 2022 17:08:24 +0100	[thread overview]
Message-ID: <YkSAeJTGAdYkYC09@stefanha-x1.localdomain> (raw)
In-Reply-To: <YkRSvDscyY+c+9yM@xz-m1.local>

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Wed, Mar 30, 2022 at 08:53:16AM -0400, Peter Xu wrote:
> On Wed, Mar 30, 2022 at 11:04:24AM +0100, Stefan Hajnoczi wrote:
> > This makes me wonder whether there is a deeper issue with the
> > pci_setup_iommu() API: the lack of per-device cleanup callbacks.
> > Per-device IOMMU resources should be freed when a device is hot
> > unplugged.
> > 
> > From what I can tell this is not the case today:
> > 
> > - hw/i386/intel_iommu.c:vtd_find_add_as() allocates and adds device
> >   address spaces but I can't find where they are removed and freed.
> >   VTDAddressSpace instances pointed to from vtd_bus->dev_as[] are leaked.
> > 
> > - hw/i386/amd_iommu.c has similar leaks.
> 
> AFAICT it's because there's no device-specific data cached in the
> per-device IOMMU address space, at least so far.  IOW, all the data
> structures allocated here can be re-used when a new device is plugged in
> after the old device unplugged.
> 
> It's definitely not ideal since after unplug (and before a new device
> plugged in) the resource is not needed at all so it's kind of wasted, but
> it should work functionally.  If to achieve that, some iommu_unplug() or
> iommu_cleanup() hook sounds reasonable.

I guess the question is whether PCI busses can be hotplugged with
IOMMUs. If yes, then there is a memory leak that matters for
intel_iommu.c and amd_iommu.c.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-03-30 16:10 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25 19:19 [PATCH v7 00/17] vfio-user server in QEMU Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 01/17] tests/avocado: Specify target VM argument to helper routines Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 02/17] qdev: unplug blocker for devices Jagannathan Raman
2022-03-29 10:08   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 03/17] remote/machine: add HotplugHandler for remote machine Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 04/17] remote/machine: add vfio-user property Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 05/17] configure: require cmake 3.19 or newer Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 06/17] vfio-user: build library Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 07/17] vfio-user: define vfio-user-server object Jagannathan Raman
2022-03-29 10:21   ` Stefan Hajnoczi
2022-03-29 14:03     ` Jag Raman
2022-03-25 19:19 ` [PATCH v7 08/17] vfio-user: instantiate vfio-user context Jagannathan Raman
2022-03-29 10:26   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 09/17] vfio-user: find and init PCI device Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 10/17] vfio-user: run vfio-user context Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 11/17] vfio-user: handle PCI config space accesses Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 12/17] vfio-user: IOMMU support for remote device Jagannathan Raman
2022-03-29 12:35   ` Stefan Hajnoczi
2022-03-29 14:12     ` Jag Raman
2022-03-29 14:48       ` Stefan Hajnoczi
2022-03-29 19:58         ` Jag Raman
2022-03-30 10:04           ` Stefan Hajnoczi
2022-03-30 12:53             ` Peter Xu
2022-03-30 16:08               ` Stefan Hajnoczi [this message]
2022-03-30 17:13                 ` Peter Xu
2022-03-31  9:47                   ` Stefan Hajnoczi
2022-03-31 12:41                     ` Peter Xu
2022-04-13 14:37                       ` Igor Mammedov
2022-04-13 19:08                         ` Peter Xu
2022-04-19  8:48                           ` Igor Mammedov
2022-04-13 14:25   ` Igor Mammedov
2022-04-13 18:25     ` Jag Raman
2022-04-13 21:59       ` Jag Raman
2022-03-25 19:19 ` [PATCH v7 13/17] vfio-user: handle DMA mappings Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 14/17] vfio-user: handle PCI BAR accesses Jagannathan Raman
2022-03-29 12:50   ` Stefan Hajnoczi
2022-03-29 15:51     ` Jag Raman
2022-03-30 10:05       ` Stefan Hajnoczi
2022-03-30 14:46         ` Jag Raman
2022-03-30 16:06           ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 15/17] vfio-user: handle device interrupts Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 16/17] vfio-user: handle reset of remote device Jagannathan Raman
2022-03-29 14:46   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 17/17] vfio-user: avocado tests for vfio-user Jagannathan Raman

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=YkSAeJTGAdYkYC09@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=bleal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=elena.ufimtseva@oracle.com \
    --cc=f4bug@amsat.org \
    --cc=jag.raman@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=john.g.johnson@oracle.com \
    --cc=john.levon@nutanix.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thanos.makatos@nutanix.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 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).