[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] VMX: wbinvd when vmentry under UC

Jan Beulich wrote:
>>>> On 29.11.13 at 15:31, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>> wrote: Andrew Cooper wrote: On 29/11/13 14:15, Liu, Jinsong wrote:
>>>> Jan Beulich wrote: 
>>>>>>>> "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 11/28/13 8:17 AM >>>
>>>>>> Liu, Jinsong wrote:
>>>>>>> Yes. reprogram_timer here just delay timer a little slot, say,
>>>>>>> 1~2ms. I think it's OK, i.e. at any point of wbinvd() operation
>>>>>>> at hypervisor, or any irq disabled area, timer interrupt in
>>>>>>> fact also has good chance to be delayed some time -- however at
>>>>>>> TIMER_SOFTIRQ, all expired thing would be executed, and
>>>>>>> re-calculated and set next time point via reprogram_timer --
>>>>>>> that's OK.
>>>>>> Comments/thoughts about this option?
>>>>> Apart from continuing to be very uncertain that this won't have
>>>>> any bad side effects, I'm also rather concerned that you deal
>>>>> with one special case interrupt here, ignoring other potentially
>>>>> high rate ones (like such coming from NICs).
>>>> Considering this, seems adding flag is the only work around way
>>>> since high freq interrupt would result in dead-like-loop. My
>>>> concern of adding flag is it's not easy to clean every possible
>>>> path, especially future extension. 
>>>> Or, do not support vt-d w/o snoop.
>>> Do you know how many systems have vt-d without snoop ?
>> Yes, that's what I need check inside Intel. Maybe not feasible idea
>> I agree. 
> But let's take a step back here: Even with the old solution, there
> wasn't any cache flushing being done when the guest was running
> in UC mode. So with what we have now we're already doing better
> than before in this regard. The primary goal here (and the criteria
> for backporting the patches) is to address XSA-60. Which, if I'm not
> mistaken, we achieved with the first three of the four initial
> patches. Patch 4 and anything beyond really are addressing a distinct
> issue. 
> Jan

The reason of 'do not support vt-d w/o snoop' is not only for XSA-60, though it 
seems got fix. My real concern comes from cacheability confliction coming from 
vt-d w/o snoop (and IPAT bit) -- same cpu can access same physical memory w/ 
different cache attributes via different mapping -- which is explicitly warned 
by Intel SDM, though until now it didn't bring other safety issue at Xen.

Xen-devel mailing list



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