[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Revisit VT-d asynchronous flush issue
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx] > Sent: Monday, November 02, 2015 7:40 PM > > > > > 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 Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |