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 1:19 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/27/2011 09:02 AM, Andrew Lutomirski wrote:
>> My current patch adds a field to pv_info.  I agree it's ugly.
>
> Hm, that's not so bad as actually adding a new op though.
>
>> 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?
>
> I don't know.  64-bit PV guests are already pretty horrid because of all
> the pagetable switching, so it may be that iret vs sysret disappears in
> the wash.  It's certainly a cleaner fix, but I would want to measure it
> before committing to it.

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.

I suspect that Sandy Bridge is just about the worst case.  syscall and
sysret are amazingly fast on Sandy Bridge.

--Andy

>
>    J
>

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