[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 12/03/2013 03:09 PM, 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.

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

_______________________________________________
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®.