[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 Thu, Jul 28, 2011 at 2:07 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/27/2011 09:33 PM, Andrew Lutomirski wrote:
>> On Sandy Bridge, a null vsyscall takes 373 ns. Without
>> VCGF_in_syscall, it's 457 ns. The change causes my little test app to
>> get cs == __USER_CS.
>
> Hm, 20% is more noticable than I would hope.  What about a regular syscall?

VCGF_in_syscall: gettimeofday() (the syscall version) takes 593 ns.
Without VCGF_in_syscall, it's 712 ns.

I'd argue for using my original approach of adding a user_64bit_mode
function -- I think it's a legitimate cleanup and Xen, for better or
worse, really does have two long mode CPL 3 selectors.  If we removed
selector 6 from the GDT, that would be a different story, but that
would probably be a more intrusive change.

--Andy

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


 


Rackspace

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