Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.05.16 at 05:19, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Xu, Quan
>> Sent: Monday, May 16, 2016 11:26 PM
>> 
>> On May 13, 2016 11:28 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> > >>> On 22.04.16 at 12:54, <quan.xu@xxxxxxxxx> wrote:
>> > > --- a/docs/misc/xen-command-line.markdown
>> > > +++ b/docs/misc/xen-command-line.markdown
>> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also
>> > specified vpmu will be turned off.
>> > >  As the virtualisation is not 100% safe, don't use the vpmu flag on
>> > > production systems (see http://xenbits.xen.org/xsa/advisory-163.html)! 
>> > >
>> > > +### vtd\_qi\_timeout (VT-d)
>> > > +> `= <integer>`
>> > > +
>> > > +> Default: `1`
>> > > +
>> > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
>> > > +
>> > > +By default, the timeout is 1ms. When you see error 'Queue invalidate
>> > > +wait descriptor timed out', try increasing this value.
>> >
>> > So when someone enables ATS, will the 1ms timeout apply to the dev iotlb
>> > invalidations too?
>> 
>> Yes,
>> The timeout is the same for IOTLB, Context, IEC and Device-TLB invalidation.
>> 
>> > If so, that's surely too short, and would ideally be adjusted
>> > automatically, but the need for a higher timeout in that case should in any
>> > event be mentioned here.
>> 
>> I can try to use 1ms for IOTLB, Context and  IEC invalidation. As mentioned, 
>> 1 ms is
>> enough for IOTLB, Context and  IEC invalidation.
>> What about 10 ms for Device-TLB (10 ms is just a higher timeout,  no 
>> specific meaning)?
> 
> I remember in earlier discussion we agreed to use 1ms as the default for both
> IOMMU-side and device-side flushes. For device-side flushes, we checked 
> internal
> HW team that 1ms is a reasonable threshold for integrated devices. It's likely
> insufficient for discrete devices. We may check any automatic adjustment 
> method
> later when it becomes a real problem. For now, please elaborate above 
> information
> in the text.

Well, taking care of automation later is fine with me, but tying
everything to a single timeout, when device iotlb invalidation may
require a much larger value, isn't.

>> > Apart from that aspect this patch seems to be ready, but will clearly need 
>> > a VT-
>> > d maintainer's ack.
>> >
>> 
>> Thanks for your review. I will also test this patch against the last commit 
>> ( I am still out
>> of office and I will do it around this Wednesday).
>> 
> 
> Jan, do you want me to ack this series now, or wait until previous series 
> handling error is checked in? (I thought you wanted the later in one of
> your replies earlier). Either way is OK to me. :-)

Well, I'm not to tell you when to ack a certain series. You should ack
it once it meets the criteria for you to ack it. The dependency on the
other series is what should be spelled out explicitly in this series, or
even better this series should be merged with the other one (to the
dependency make most obvious). But I'm repeating myself...

Jan


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