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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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


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