[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.