[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?
--Andy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
