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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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.

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). 

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

Thanks
Kevin

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