[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 5/7] memory: Allow replay of IOMMU mapping notific
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [PATCH 5/7] memory: Allow replay of IOMMU mapping notifications |
Date: |
Fri, 25 Sep 2015 21:33:49 +1000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Fri, Sep 25, 2015 at 01:20:12PM +0200, Paolo Bonzini wrote:
>
>
> On 24/09/2015 06:33, David Gibson wrote:
> > When we have guest visible IOMMUs, we allow notifiers to be registered
> > which will be informed of all changes to IOMMU mappings. This is used by
> > vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings.
> >
> > However, unlike with a memory region listener, an iommu notifier won't be
> > told about any mappings which already exist in the (guest) IOMMU at the
> > time it is registered. This can cause problems if hotplugging a VFIO
> > device onto a guest bus which had existing guest IOMMU mappings, but didn't
> > previously have an VFIO devices (and hence no host IOMMU mappings).
> >
> > This adds a memory_region_register_iommu_notifier_replay() function to
> > handle this case. As well as registering the new notifier it replays
> > existing mappings. Because the IOMMU memory region doesn't internally
> > remember the granularity of the guest IOMMU it has a small hack where the
> > caller must specify a granularity at which to replay mappings.
> >
> > If there are finer mappings in the guest IOMMU these will be reported in
> > the iotlb structures passed to the notifier which it must handle (probably
> > causing it to flag an error). This isn't new - the VFIO iommu notifier
> > must already handle notifications about guest IOMMU mappings too short
> > for it to represent in the host IOMMU.
> >
> > Signed-off-by: David Gibson <address@hidden>
>
> The patch is okay, just two questions:
>
> 1) Is there a case where using the no-replay functions makes sense?
I'm not sure. I think vfio is the only user so far, so I guess that's
technically a no. I was reluctant to change the interface and
semantics just off the bat, though.
> 2) You could add a ->replay function to the iommu_ops to optimize it, if
> you want.
Yes. Originally I was going to implement with a ->replay function,
before I realised I didn't actually need it. I figure we can optimize
when and if it proves necessary.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpl9szMARnVJ.pgp
Description: PGP signature
- [Qemu-ppc] [PATCH 4/7] vfio: Record host IOMMU's available IO page sizes, (continued)
[Qemu-ppc] [PATCH 7/7] vfio: Expose a VFIO PCI device's group for EEH, David Gibson, 2015/09/24
[Qemu-ppc] [PATCH 3/7] vfio: Check guest IOVA ranges against host IOMMU capabilities, David Gibson, 2015/09/24
[Qemu-ppc] [PATCH 6/7] vfio: Allow hotplug of containers onto existing guest IOMMU mappings, David Gibson, 2015/09/24
[Qemu-ppc] [PATCH 1/7] vfio: Remove unneeded union from VFIOContainer, David Gibson, 2015/09/24