Re: XSA-60 - how to get back to a sane state

[George Dunlap <george.dunlap@eu.citrix.com>]

On 12/03/2013 03:09 PM, Jan Beulich wrote:
>>>> On 03.12.13 at 15:30, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 03.12.13 at 04:06, "Liu, Jinsong" <jinsong.liu@intel.com> 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.

Is this still about guests doing wbinvd?  As Jan said, there is no point 
in doing wbinvd piecemeal: if it's not 100% reliable (to the best of our 
knowledge), then the more unreliable the better really.

  -George