Re: [GIT PULL] x86 fixes
From: Cyrill Gorcunov
Date: Sat Jan 16 2010 - 17:12:23 EST
On Sat, Jan 16, 2010 at 09:16:56PM +0000, Ian Campbell wrote:
> > |
> > | > Yeah, I didn't found any explicit %ss reloading for this _particular_
> > | > case (as I marked in patch changelog). So the only suspicious is Xen
> > | > itself. So as only Christian get ability to test -- we will see the
> > | > results.
> > |
> > | The difference with Xen is that it must squash the RPL of SS (to 3 for
> > | 64 bit and 1 for 32 bit, 32 bit doesn't matter here though). Perhaps a
> > | NULL selector can only have RPL==0? (I'm away from my architecture docs
> > | so I can't check). In any case specifying a non-NULL SS selector allows
> > | the squashing to occur correctly.
> > |
> > In turn reported said that only _this_ patch alone doesn't help him and
> > Ian replied we need both patches.
> > Ian CC'ed if details needed.
> Thanks, I think you've covered or quoted everything.
> Although I think Linus' basic point is still valid -- why isn't a valid
> SS needed for 32 bit? The selectors have real meaning there even for
> native, don't they?
Well, the point was (I suppose) why we've started to set SS selector here
at all. It's due to Xen. Old code was doing so, and that happened Xen is
relating on it (as you actually said).
Also this is kernel thread which is supposed to execute in kernel space.
And kernel itself already set SS selector when it needs. So to eliminate
redunant operations we don't set SS here. And if there was not such
issue on a Xen side -- we would not set SS here as well.
Again, to be fair I just don't have rights to blame Xen here -- I rely on your
and Christian reports only.
> (I'm travelling all tomorrow and unlikely to be getting mail).
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/