A question about SYSENTER/SYSEXIT in HVM guest

A question about SYSENTER/SYSEXIT in HVM guest

[Guofu Xiang]

[-- Attachment #1.1: Type: text/plain, Size: 1080 bytes --]

The CPU type of our server is Intel Xeon E5310, and the OS is Fedora 8. Xen
3.2 is installed by compilation. When the HVM guest is x86_32 Fedora 8, the
system call is implemented by instruction - *int $80h*. Our debug result by
gdb is as follow.

Dump of assembler code for function __kernel_vsyscall:
0xb7f87400 <__kernel_vsyscall+0>:       int    $0x80
0xb7f87402 <__kernel_vsyscall+2>:       ret
End of assembler dump.

However, when the HVM guest is x86_64 Fedora 8, the system call is
implemented by instruction - *syscall*. The debug result is as fellow:

Dump of assembler code for function getuid:
0x00000036e7296220 <getuid+0>:  mov    $0x66,%eax
0x00000036e7296225 <getuid+5>:  syscall
0x00000036e7296227 <getuid+7>:  retq

As far as I know, fast system call is implemented by *sysenter* on Intel
CPU, and *syscall* on AMD CPU. Why the debug result is *syscall*, rather
than *sysenter*?
If the HVM guest is x86_32 Fedora 8, can we set the system call
implementation by *sysenter*? In x86_64 OS, is all system call implemented
by *syscall*?

Thank you for your response!

[-- Attachment #1.2: Type: text/html, Size: 1371 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: A question about SYSENTER/SYSEXIT in HVM guest

[Christoph Egger]

On Monday 06 April 2009 15:11:52 Guofu Xiang wrote:
> The CPU type of our server is Intel Xeon E5310, and the OS is Fedora 8. Xen
> 3.2 is installed by compilation. When the HVM guest is x86_32 Fedora 8, the
> system call is implemented by instruction - *int $80h*. Our debug result by
> gdb is as follow.
>
> Dump of assembler code for function __kernel_vsyscall:
> 0xb7f87400 <__kernel_vsyscall+0>:       int    $0x80
> 0xb7f87402 <__kernel_vsyscall+2>:       ret
> End of assembler dump.
>
> However, when the HVM guest is x86_64 Fedora 8, the system call is
> implemented by instruction - *syscall*. The debug result is as fellow:
>
> Dump of assembler code for function getuid:
> 0x00000036e7296220 <getuid+0>:  mov    $0x66,%eax
> 0x00000036e7296225 <getuid+5>:  syscall
> 0x00000036e7296227 <getuid+7>:  retq
>
> As far as I know, fast system call is implemented by *sysenter* on Intel
> CPU, and *syscall* on AMD CPU. Why the debug result is *syscall*, rather
> than *sysenter*?
> If the HVM guest is x86_32 Fedora 8, can we set the system call
> implementation by *sysenter*? In x86_64 OS, is all system call implemented
> by *syscall*?
>
> Thank you for your response!

The Linux kernel has several vdso pages, one for int 0x80, one for syscall and 
one for sysenter. The Linux kernel maps one of them into userspace
depending on the cpuid vendor string.
In 64bit mode, the glibc always uses syscall, therefore all
applications use syscall instruction. If you run a 32bit application,
the glibc uses the vdso page (if its version is new enough or patched by the 
distributor).

I don't know the exact version since glibc uses the vdso, Slackware 12.1.0
comes with an unpatched glibc 2.4 and it doesn't use the vdso page.
It uses syscall in 64bit mode and int 0x80 in 32bit mode.

SLES 10.0 comes with a patched glibc 2.3.5 and uses the vdso page in 32bit
mode.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: A question about SYSENTER/SYSEXIT in HVM guest

[Christoph Egger]

On Monday 06 April 2009 16:11:19 Guofu Xiang wrote:
>    glibc 2.7-2 is the default c library in Fedora 8. Does this version can
> be patched in order to set the system call implementation with *sysenter
> *in x86_32 Fedora 8?

I don't know since when glibc officially uses the vdso page.
You can see with gdb with single stepping on instruction level
and see if it jumps into vdso page or not.

The gdb commands you need for that are:

break
display /5i $eip
run
stepi
finish

Christoph


>
>
> 2009/4/6 Christoph Egger <Christoph.Egger@amd.com>
>
> >  On Monday 06 April 2009 15:11:52 Guofu Xiang wrote:
> > > The CPU type of our server is Intel Xeon E5310, and the OS is Fedora 8.
> >
> > Xen
> >
> > > 3.2 is installed by compilation. When the HVM guest is x86_32 Fedora 8,
> >
> > the
> >
> > > system call is implemented by instruction - *int $80h*. Our debug
> > > result
> >
> > by
> >
> > > gdb is as follow.
> > >
> > > Dump of assembler code for function __kernel_vsyscall:
> > > 0xb7f87400 <__kernel_vsyscall+0>:       int    $0x80
> > > 0xb7f87402 <__kernel_vsyscall+2>:       ret
> > > End of assembler dump.
> > >
> > > However, when the HVM guest is x86_64 Fedora 8, the system call is
> > > implemented by instruction - *syscall*. The debug result is as fellow:
> > >
> > > Dump of assembler code for function getuid:
> > > 0x00000036e7296220 <getuid+0>:  mov    $0x66,%eax
> > > 0x00000036e7296225 <getuid+5>:  syscall
> > > 0x00000036e7296227 <getuid+7>:  retq
> > >
> > > As far as I know, fast system call is implemented by *sysenter* on
> > > Intel CPU, and *syscall* on AMD CPU. Why the debug result is *syscall*,
> > > rather than *sysenter*?
> > > If the HVM guest is x86_32 Fedora 8, can we set the system call
> > > implementation by *sysenter*? In x86_64 OS, is all system call
> >
> > implemented
> >
> > > by *syscall*?
> > >
> > > Thank you for your response!
> >
> > The Linux kernel has several vdso pages, one for int 0x80, one for
> > syscall and
> > one for sysenter. The Linux kernel maps one of them into userspace
> > depending on the cpuid vendor string.
> > In 64bit mode, the glibc always uses syscall, therefore all
> > applications use syscall instruction. If you run a 32bit application,
> > the glibc uses the vdso page (if its version is new enough or patched by
> > the
> > distributor).
> >
> > I don't know the exact version since glibc uses the vdso, Slackware
> > 12.1.0 comes with an unpatched glibc 2.4 and it doesn't use the vdso
> > page. It uses syscall in 64bit mode and int 0x80 in 32bit mode.
> >
> > SLES 10.0 comes with a patched glibc 2.3.5 and uses the vdso page in
> > 32bit mode.
> >
> > Christoph
> >
> >
> > --
> > ---to satisfy European Law for business letters:
> > Advanced Micro Devices GmbH
> > Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
> > Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
> > Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> > Registergericht Muenchen, HRB Nr. 43632



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632