[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 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
|
