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

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



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

Jan


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


 


Rackspace

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