Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> On 25.12.2015 at 9:51am, <Tian, Kevin> wrote:
> > From: Jan Beulich [mailto:jbeulich@xxxxxxxx]
> > Sent: Wednesday, December 23, 2015 6:39 PM
> >
> > >>> Quan Xu <quan.xu@xxxxxxxxx> 12/23/15 9:26 AM >>>
> > >This patches are based on Kevin Tian's previous discussion 'Revisit
> > >VT-d asynchronous
> > flush issue'.
> > >Fix current timeout concern and also allow limited ATS support in a light 
> > >way:
> > >
> > >1. Check VT-d Device-TLB flush error.
> > >This patch checks all kinds of error and all the way up the call
> > >trees of VT-d Device-TLB
> > flush.
> > >
> > >2. Reduce spin timeout to 1ms, which can be boot-time changed with
> > 'iommu_qi_timeout_ms'.
> > >For example:
> > >multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100
> > >
> > >3. Fix vt-d Device-TLB flush timeout issue.
> > >Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. The
> > >coming patch set will fix it.
> >
> > There must have been a misunderstanding: Your earlier outline didn't
> > indicate you mean to introduce panics here, even if only temporarily.
> > I'm afraid I'm not currently willing to take any conceptually wrong
> > patches anymore with just the promise of fixing the issue(s) later
> > (and I think we've mentioned this in some past discussion on the list,
> > albeit unlikely in the context of any of your work). This may mean that the
> earlier described ordering of things you mean to do needs changing.
> >
> > I'm sorry that you're hit first by this, the more that it was not you
> > but colleagues of yours causing this change to the acceptance model.
> >
> 
> I believe Quan's point here is to point out the current fact. That is why he 
> said a
> coming patch will fix that behavior based on earlier discussion. It's not 
> related
> with this patch set which is only step-1 in his plan.
> 

Yes.

> Quan, I think it's confusing for you to miss description of this step-1 
> patch, with
> some TODO discussions together for later steps. It'd be good for the message
> staying with whatever is changed in this Device-TLB flush fix, and then in the
> end you list several TODO bullets to let community know future plan (again, 
> just
> list of expected tasks. no need to discuss them until you have related code
> ready).
> 

I will fix it in next v5.

> This way it should make reviewers more focus on the points you want to get
> reviewed. :-)

Thanks Jan / Kevin. :):)

-Quan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel