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

Re: [Xen-devel] [PATCH v9 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

  • To: Jan Beulich <JBeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
  • Date: Sat, 20 Jan 2018 11:10:29 +0000
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Sat, 20 Jan 2018 11:11:10 +0000
  • Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEUHBwcUFBQpKSlGRkZhYWF9fX2Xl5eysrLMzMxFF+rXAAACaElEQVQ4y21UQXbbIBQE9wJALmAg6ToWON22FrhZthHgbvssUPathC7QWMful2JHSmtWwGg+zPxBCE0DU4QoJQgRgsg4w2gJjBNE8PjFBZgnQMBs+uZ1NQNQjZO3BV4AGDFC0f+l4DBG0VUAM4yv7SO8IgRdHXQ+A78HKL5OAeCfNQV5cHX8DsBUyIJKtYbt98BKaGNCKjfgFVkqYVLbkHKsRsbSCSa0T6npIqLrpRBgQKHUpQmgs9eEKaiUcooE8WWfCGVnBiUcn1uF2XhbfmN9apKnmMP2K4kizKkQWxuaVNOpU2cACIyxO1Po8ETHcXEDMVnozcejkAYA9iaD4pU0ZvNQ8VurNnTuFAYVtuIPUZW25PjDIjQAlGyffIiRQxoWAZBmJ0LTdW2Nyc0iP3DqRhxizvGJkBWZmyFVyZkddWzmBoIBVMpCCJ1CFzl98xav4VJKSSD45KbUT75ixikTphDSRh8+Uz7JLgUTAgAFwzqzjxc/nDY7WUApqY0OMdTwCKZSXplSKkgIRCHElCp8ZnhnKqXuwcNbk1L0VXE+I9alUXoHlLHl3mv7/dWQlJwtjREC7mu9L/U2jQyMUuO2EDS4q9Kl2ddm232bxIE5pjJuVwiljNn/Cfv25/T0cu5cZbwHGVq7h/zp0B4n3S99V/utD+Uo8BiGx9xCsOAV5z7/tjo4Z4z1Lvb90KZ7eFOoOeXOukqF2seo234YYuaQPpRP+cVZU5adT1Edun5Iz3z8fTz3+eSDh0Ip1c7zx1MaijGzTd/3MbRuBHz8cvcVgCMBRpOHvgu59WDhoat+nIZm+LWm9C/aaaGq5DCP9QAAAABJRU5ErkJggg==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, 2018-01-19 at 08:07 -0700, Jan Beulich wrote:
> > > > On 19.01.18 at 15:48, <andrew.cooper3@xxxxxxxxxx> wrote:
> > vcpu pointers are rather more susceptible to false aliasing in the case
> > that the 4k memory allocation behind struct vcpu gets reused.
> > 
> > The risks are admittedly minute, but this is a much safer option.
> Oh, right, I didn't consider the case of the vCPU (and domain)
> having gone away in the meantime. Mind extending the comment
> to clarify this?

I look at this and figured I didn't care about aliasing. Sure, we might
not do the IBPB if the stale pointer is aliased and we switch from a
now-dead vCPU to a new vCPU. But good luck exploiting the new vCPU from
an old domain that's now dead!

I actually thought Andrew changed from pointers just because of the
'ick' factor of keeping a known-stale pointer around and using it for
*comparison* but having to careful avoid ever *dereferencing* it (as my
debugging patch in context_switch() did... oops!)

> > David found that transitions to idle and back to the same vcpu were
> > reliably taking an unnecessary IBPB.

I'll repeat my caveat there — I observed this on our ancient Xen
4.mumble not current HEAD. But the code here looks remarkably similar;
it hasn't changed for a while.

> I understand that, but there was no explanation whatsoever as
> to why that is.

Looks like we set per_cpu(curr_vcpu)=next every time we switch, even if
we are switching to the idle domain. Which is why I added per_cpu(last)
specifically to be updated only when it *isn't* an idle vCPU.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Xen-devel mailing list



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