[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 2/3] memory: introduce IOMMUOps.notify_flag_c
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v4 2/3] memory: introduce IOMMUOps.notify_flag_changed |
Date: |
Wed, 14 Sep 2016 20:37:34 +1000 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Wed, Sep 14, 2016 at 03:49:41PM +0800, Peter Xu wrote:
> On Wed, Sep 14, 2016 at 05:22:40PM +1000, David Gibson wrote:
> > On Wed, Sep 14, 2016 at 03:12:43PM +0800, Peter Xu wrote:
> > > On Wed, Sep 14, 2016 at 03:55:28PM +1000, David Gibson wrote:
> > >
> > > [...]
> > >
> > > > > -static void vtd_iommu_notify_started(MemoryRegion *iommu)
> > > > > +static void vtd_iommu_notify_flag_changed(MemoryRegion *iommu,
> > > > > + IOMMUNotifierFlag old,
> > > > > + IOMMUNotifierFlag new)
> > > > > {
> > > > > VTDAddressSpace *vtd_as = container_of(iommu, VTDAddressSpace,
> > > > > iommu);
> > > >
> > > > Shouldn't this have a sanity check that the new flags doesn't include
> > > > MAP actions?
> > >
> > > See your r-b for patch 3, thanks! So skipping this one.
> > >
> > > [...]
> > >
> > > > > +static void spapr_tce_notify_flag_changed(MemoryRegion *iommu,
> > > > > + IOMMUNotifierFlag old,
> > > > > + IOMMUNotifierFlag new)
> > > > > +{
> > > > > + if (old == IOMMU_NOTIFIER_NONE && new == IOMMU_NOTIFIER_ALL) {
> > > > > + spapr_tce_notify_started(iommu);
> > > > > + } else if (old == IOMMU_NOTIFIER_ALL && new ==
> > > > > IOMMU_NOTIFIER_NONE) {
> > > > > + spapr_tce_notify_stopped(iommu);
> > > > > + }
> > > >
> > > > This is wrong. We need to do the notify_start and stop actions if
> > > > *any* bits are set in the new/old flags, not just if all of them are
> > > > set.
> > >
> > > Power should need both, right? I can switch all
> > >
> > > "== IOMMU_NOTIFIER_ALL"
> > >
> > > into:
> > >
> > > "!= IOMMU_NOTIFIER_NONE"
> >
> > Yes, that should be right.
> >
> > > in the next version if you like, but AFAICT they are totally the
> > > same.
> >
> > Again, only if you assume things about how the notifiers will be used,
> > which is not a good look when designing an interface.
>
> This should not be related to the interface at all?
>
> I was based on the assumption that "Power cannot support either one of
> MAP/UNMAP, but only if both exist".
Huh? I have no idea what you mean by that.
Power can support notifying both map and unmap events just fine - but
in order to provide *any* notifications, it has to disable KVM
acceleration of the guest-side IOMMU (otherwise qemu won't know about
any changes to the IOMMU state).
So the change you you suggested before to != IOMMU_NOTIFIER_NONE is
exactly correct, anything else is not.
> To be more specific, we possibly
> can have this at the beginning of flags_changed():
>
> assert(old == IOMMU_NOTIFIER_NONE || old == IOMMU_NOTIFIER_ALL);
> assert(new == IOMMU_NOTIFIER_NONE || new == IOMMU_NOTIFIER_ALL);
>
> To make sure nothing will go wrong.
Hmm.. I really get the feeling you're confusing constraints of the
guest side with constraints of the host side.
--
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
signature.asc
Description: PGP signature
[Qemu-devel] [PATCH v4 2/3] memory: introduce IOMMUOps.notify_flag_changed, Peter Xu, 2016/09/08
[Qemu-devel] [PATCH v4 3/3] intel_iommu: allow UNMAP notifiers, Peter Xu, 2016/09/08
Re: [Qemu-devel] [PATCH v4 0/3] Introduce IOMMUNotifier struct, no-reply, 2016/09/09