From: Igor Mammedov <imammedo@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: "eduardo@habkost.net" <eduardo@habkost.net>,
Elena Ufimtseva <elena.ufimtseva@oracle.com>,
"dgilbert@redhat.com" <dgilbert@redhat.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>,
qemu-devel <qemu-devel@nongnu.org>,
"f4bug@amsat.org" <f4bug@amsat.org>,
Alex Williamson <alex.williamson@redhat.com>,
Kanth Ghatraju <kanth.ghatraju@oracle.com>,
"berrange@redhat.com" <berrange@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"thanos.makatos@nutanix.com" <thanos.makatos@nutanix.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"eblake@redhat.com" <eblake@redhat.com>
Subject: Re: [PATCH v7 12/17] vfio-user: IOMMU support for remote device
Date: Wed, 13 Apr 2022 16:37:35 +0200 [thread overview]
Message-ID: <20220413163735.5321c2ec@redhat.com> (raw)
In-Reply-To: <YkWhXUI/Vr7++1ru@xz-m1.local>
On Thu, 31 Mar 2022 08:41:01 -0400
Peter Xu <peterx@redhat.com> wrote:
> On Thu, Mar 31, 2022 at 10:47:33AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Mar 30, 2022 at 01:13:03PM -0400, Peter Xu wrote:
> > > On Wed, Mar 30, 2022 at 05:08:24PM +0100, Stefan Hajnoczi wrote:
> > > > 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.
> > >
> > > It can't, and we only support one vIOMMU so far for both (commit
> > > 1b3bf13890fd849b26). Thanks,
> >
> > I see, thanks!
> >
> > Okay, summarizing options for the vfio-user IOMMU:
> >
> > 1. Use the same singleton approach as existing IOMMUs where the
> > MemoryRegion/AddressSpace are never freed. Don't bother deleting.
> >
> > 2. Keep the approach in this patch where vfio-user code manually calls a
> > custom delete function (not part of the pci_setup_iommu() API). This
> > is slightly awkward to do without global state and that's what
> > started this discussion.
> >
> > 3. Introduce an optional pci_setup_iommu() callback:
> >
> > typdef void (*PCIIOMMUDeviceUnplug)(PCIBus *bus, void *opaque, int devfn);
> >
> > Solves the awkwardness of option #2. Not needed by existing IOMMU
> > devices.
>
> Looks all workable to me. One tiny thing is if we'd like 3) we may want to
> pass over the PCIDevice* too because in this case IIUC we'd need to double
> check the device class before doing anything - we may not want to call the
> vfio-user callbacks for general emulated devices under the same pci bus.
>
> I think we could also fetch that from PCIBus.devices[devfn] but that's just
> not as obvious.
>
> Option 4) is as mentioned previously, that we add another device unplug
> hook that can be registered per-device. I just didn't think thoroughly on
can you expand on why per device hook is needed?
> how it would interact with the current HotplugHandler design yet.. it looks
> quite similar but so far it's either for the machine type or pci bus, not
> capable of registering on one single device (and it's always a mistery to
> me why we'd rather ignore the per-bus hook if the machine hook
> existed.. that's in qdev_get_hotplug_handler).
machine hook is there for bus-less devices mainly, if it's not defined
code will fallback to bus handler if any exists.
However machine hook can also be used to override default hotplug chain
to do to implement non trivial plug/unplug flow.
for example see pc_get_hotplug_handler(), corresponding
pc_machine_device_[pre_plug|plug|unplug...]_cb() where
plug/unplug chain is altered for some PCI devices types.
Perhaps the same can be done for vfio.
>
> Copying Igor too.
>
next prev parent reply other threads:[~2022-04-13 14:39 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
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 [this message]
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=20220413163735.5321c2ec@redhat.com \
--to=imammedo@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=stefanha@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).