Re: [PATCH] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests

From: Boris Ostrovsky
Date: Thu Apr 30 2015 - 18:26:00 EST


On 04/30/2015 03:35 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:30 PM, Boris Ostrovsky
<boris.ostrovsky@xxxxxxxxxx> wrote:
On 04/30/2015 03:17 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 12:08 PM, Boris Ostrovsky
<boris.ostrovsky@xxxxxxxxxx> wrote:
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.

This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.

Since the problem that the commit is trying to address would have to be
fixed in the hypervisor (if it in fact exists under Xen) there is no
reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.

Seems reasonable.

Have you run the test case on a Xen PV guest on AMD? It's possible
that Xen is affected, since the old accidental workaround that we
deleted was in the vdso and probably would have worked on Xen.

Is there a specific test that would trigger this bug? I
booted/suspended/resumed a bunch of various guest types on both AMD and
Intel but not much more than that. What is the commit that you deleted?

I doubt that a change in the guest could suddenly start triggering this
issue but I will take a look at hypervisor code.
http://article.gmane.org/gmane.linux.kernel/1937899

The change was that we stopped reloading ss after 32-bit sysret in the
vdso trampoline. Before we always reloaded ss in userspace before
doing any stack operations.

I have no idea whether this was deliberate. It had done that (with
the attendant performance hit) since the very beginning, and there was
no comment explaining why.

The test passed. Which I guess is not surprising given that interrupt handling is done by the hypervisor.


-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/