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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

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.

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