[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping |
Date: |
Tue, 13 Sep 2016 17:13:23 +0300 |
On Tue, Sep 13, 2016 at 05:11:00PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 13, 2016 at 03:38:38PM +0800, Peter Xu 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...
> >
> > Thanks,
> >
> > -- peterx
>
> By now it's minimally intrusive, so yes, I think I'll merge
> and we can apply fixes on top incrementally.
> E.g. would you like to post the suggested comment as a patch?
>
> --
> MST
Sorry, in fact I was referring to amd iommu itself, while posting
in the int remapping thread.
There will be more versions of this one
so including a comment there directly is better.
--
MST
- Re: [Qemu-devel] [v4 2/6] hw/i386: enforce SID verification, (continued)
- [Qemu-devel] [v4 3/6] hw/iommu: Prepare for AMD IOMMU interrupt remapping, David Kiarie, 2016/09/12
- [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, David Kiarie, 2016/09/12
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, Peter Xu, 2016/09/12
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, David Kiarie, 2016/09/12
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, Peter Xu, 2016/09/12
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, David Kiarie, 2016/09/12
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, Peter Xu, 2016/09/13
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, Michael S. Tsirkin, 2016/09/13
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [v4 4/6] hw/iommu: AMD IOMMU interrupt remapping, David Kiarie, 2016/09/14