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

Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).

On Wed, Jul 27, 2011 at 11:40 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/26/2011 07:17 PM, Andrew Lutomirski wrote:
>> On Tue, Jul 26, 2011 at 7:37 PM, j.fitz.inge@xxxxxxxxx <jeremy@xxxxxxxx> 
>> wrote:
>>> The correct fix is to just look at the cpl in cs and ignore the rest of the
>>> selector.
>> No.  All three of these code paths are trap handlers that are trying
>> to distinguish between 64-bit and 32-bit segments.  The CPL is 3 in
>> either case.
> Oh, hm.
>> It looks like the reason I didn't find the code that it references
>> TRAP_syscall not VCGF_in_syscall.  Yay for grep-unfriendly code.
>> Barring a better idea, I'll implement a new paravirt op.
> Ugh.  I'd really like to avoid that.

My current patch adds a field to pv_info.  I agree it's ugly.

How terrible would it be to stop using VCGF_in_syscall so we can keep
__USER_CS?  Is there a real performance advantage to VCGF_in_syscall?


Xen-devel mailing list



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