From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Jinsong Liu <jinsong.liu@intel.com>
Cc: Keir Fraser <keir@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Zhenzhong Duan <zhenzhong.duan@oracle.com>,
Donald D Dugger <donald.d.dugger@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: XSA-60 - how to get back to a sane state
Date: Wed, 4 Dec 2013 15:55:43 +0000 [thread overview]
Message-ID: <529F507F.2030304@eu.citrix.com> (raw)
In-Reply-To: <529F2B260200007800109FF3@nat28.tlf.novell.com>
On 12/04/2013 12:16 PM, Jan Beulich wrote:
>>>> On 04.12.13 at 13:04, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> 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.
>>>
>> 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?
-George
next prev parent reply other threads:[~2013-12-04 15:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 14:28 XSA-60 - how to get back to a sane state Jan Beulich
2013-12-02 19:43 ` George Dunlap
2013-12-03 2:21 ` Andrew Cooper
2013-12-03 3:06 ` Liu, Jinsong
2013-12-03 8:00 ` Jan Beulich
2013-12-03 14:30 ` Liu, Jinsong
2013-12-03 15:09 ` Jan Beulich
2013-12-03 15:14 ` George Dunlap
2013-12-04 12:04 ` Liu, Jinsong
2013-12-04 12:16 ` Jan Beulich
2013-12-04 15:55 ` George Dunlap [this message]
2013-12-04 16:09 ` Jan Beulich
2013-12-04 16:03 ` Liu, Jinsong
2013-12-04 16:14 ` Jan Beulich
2013-12-04 16:23 ` Liu, Jinsong
2013-12-03 7:57 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529F507F.2030304@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=donald.d.dugger@intel.com \
--cc=jinsong.liu@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
--cc=zhenzhong.duan@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.