Re: [Xen-devel] XSA-60 - how to get back to a sane state

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.12.13 at 16:55, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 12/04/2013 12:16 PM, Jan Beulich wrote:
>>>>> On 04.12.13 at 13:04, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>> Jan Beulich wrote:
>>>>>>> On 03.12.13 at 15:30, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>>>> Jan Beulich wrote:
>>>>>>>>> On 03.12.13 at 04:06, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>>>>> wrote:
>>>>>>> I also vote option 2, but only revert 86d60e85, keeping 62652c00
>>>>>>> (wbinvd at vmx_ctxt_switch_to) since it's used to avoid being
>>>>>>> polluted when vcpu migrate to another cpu.
>>>>>> Please explain this in more detail. Both Andrew and I are concerned
>>>>>> about this extra, but pretty pointless (without being done so too in
>>>>>> other cases) wbinvd(). In particular you'd have to explain what its
>>>>>> counterpart was in the code prior to your four patch XSA-60 series.
>>>>> The wbinvd at vmx_ctxt_switch_to is for case like
>>>>> 1. vcpu runs at cpu A, flushing cache at vmx_handle_cd;
>>>>> 2. then the vcpu may switch out and migrate to cpu B;
>>>>> 3. historically cpu B may has cacheline polluted;
>>>>> so when the vcpu is scheduled to cpu B, we need flush cache.
>>>> But you didn't clarify whether/how this case was taken care of
>>>> _before_ your XSA-60 patches.
>>>>
>>> I didn't understand your question. What do you mean by 'before my XSA-60
>>> patches'?
>> Before your 4 patch series was applied (e.g. consider plain
>> 4.3.1) - how was the situation taken care of that your change
>> to vmx_ctxt_switch_to() is intended to deal with?
> 
> It sounds like Jan is saying: We would only consider a patch that would 
> fix regressions in functionality caused by the 4-patch XSA-60 series.  
> Was there the possibility for cacheline pollution in the scenario you 
> describe above before XSA-60 was fixed?  If not, then this is a 
> regression and we might consider a patch to restore that functionality.  
> If there was the possibility of the above scenario before the XSA-60 
> series, then it's not a regression; and therefore probably not something 
> we want to accept at this point.
> 
> Do I understand you properly, Jan?

Yes, thanks for wording it in yet another way.

Jan


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