[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Revisit VT-d asynchronous flush issue
>>> On 03.11.2015 at 10:27, <Tian, Kevin> wrote: > > > Based on above information, we propose to continue spin-timeout > > > model w/ some adjustment, which fixes current timeout concern and > > > also allows limited ATS support in a light way: > > > > > > 1) reduce spin timeout to 1ms, which can be boot-time changed up to > > > 10ms. > > > > If this is going to be command line configurable, don't have an upper limit. > > > > Given the uncertainty with external devices, it might be necessary to > > experiment with timeouts greater than 10ms. > > That also works. > > > > > > > > > 2) if timeout expires, kill the VM which the target device is > > > assigned to. Optionally hypervisor may mark device non-assignable. > > > > > > It works for devices w/o ATS. It works for integrated devices w/ ATS. > > > It might or might not work for discrete devices w/ ATS, but we can > > > re-evaluate the gain vs. software complexity of async flush until we > > > see many discrete devices breaking the timeout assumptions in the > > > future. > > > > > > Thoughts? > > > > As presented, this is probably an improvement, but I am concerning > > with the case of external devices. > > > > Then again, as none of this currently works at all, we are not in a > > worse state. > > > > Understood. So based on your and Jan's comments, let's go with this proposal > first. Thanks! I will take Kevin's approach and send out patch set ASAP. -Quan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |