Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

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

>> >>> On 09.10.2015 at 15:18 <JBeulich@xxxxxxxx> wrote:
> >>> On 09.10.15 at 09:06, <quan.xu@xxxxxxxxx> wrote:
> >> > >>>On 08.10.2015 at 16:52 <JBeulich@xxxxxxxx> wrote:
> >> >>> On 07.10.15 at 19:02, <quan.xu@xxxxxxxxx> wrote:
 
> >> > __scheme B__
> >> > Q1: - when to take the references?
> >> >
> >> >     take the reference when the IOMMU entry is _
> removed/overwritten_;
> >> >     in detail:
> >> >      --iommu_unmap_page(), or
> >> >      --ept_set_entry() [Once IOMMU shares EPT page table.]
> >> >
> >> >     * Make sure IOMMU page should not be reallocated for
> >> >      another purpose until the appropriate invalidations have been
> >> >      performed.
> >> >     * in this case, it does not matter hot-plug ATS device
> >> > pass-through or ATS device assigned in domain initialization.
> >> >
> >> > Q2 / Q3:
> >> >     The same as above __scheme A__ Q2/Q3.
> >> >
> >> > One question: is __scheme B__ safe? If it is safe, I prefer __scheme 
> >> > B__..
> >>
> >> While at the first glance this looks like a neat idea -
> >
> >
> > I think this is safe and a good solution.
> > I hope you can review into the __scheme B__. I need _Acked-by_ you and
> > Tim Deegan.
> 
> What do you mean here?

Just verify it.
If it is working, I continue to write patch based on it.
If it is not working, I continue to research ..


> I'm not going to ack a patch that hasn't even got
> written, and while scheme B looks possible, I might still overlook something, 
> so I
> also can't up front ack that model (which may then lead to you expecting that
> once implemented it gets accepted).


I am getting started to write patch based on the __scheme B__ and send out ASAP 
.
Thanks 

Quan


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