Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping

[David Kiarie]

On Tue, Sep 13, 2016 at 10:38 AM, Peter Xu <address@hidden> wrote:

> On Mon, Sep 12, 2016 at 03:45:48PM +0300, David Kiarie wrote:
> > > When we say cache here, we are mostly talking about GSI routes in
> > > kernel, right? Since we still don't have other kind of interrupt
> > > caches AFAIK. If so, GSI routes should already been setup even if the
> > > interrupts are not triggered for a single time. So we need to
> > > invalidate them even ir_cache == false.
> > >
> >
> > You're right but I'm not sure how to implement that while avoiding
> > triggering the notifier numerous pointless times during boot.
> >
> >
> > > I think the problem is why cache invalidations during boot will bug
> > > the system. Any clue?
> > >
> >
> > The issue is not too many invalidations. I don't have a very clear idea
> of
> > how notifiers work but I would assume it spawns a thread or they somehow
> > use a multithreaded approach which would mean triggering the notifier too
> > many times within a very short period many trigger a bunch of issues.
>
> No thread is spawn, we just call the notifier callbacks.
>
> For me it's fairly acceptable that guest sends lots of invalidations
> during boot. That should not lead to any functional issues. If there
> is, then something might be wrong.
>
> I don't know whether mst will like to merge this series even without
> fixing this. Anyway I would still prefer to root cause the issue, or
> at least comment this out in the commit message (or codes somewhere)
> so that we know there is something TBD and might cause misterious
> troubles...
>

Unfortunately, I, since recently can't reproduce this issue. I am however
going to change the current code so I invalidate kernel interrupt cache
each time AMD IOMMU issues an invalidate command(hence will get rid of the
ir_cache variable and it's dependency).

Thanks for taking time to review this patchset a new version coming up soon!


> Thanks,
>
> -- peterx
>