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).

[Andrew Lutomirski <luto@xxxxxxx>]

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?

--Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel