All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: xen-devel@lists.xensource.com
Cc: Guofu Xiang <whxgf1984@gmail.com>
Subject: Re: A question about SYSENTER/SYSEXIT in HVM guest
Date: Mon, 6 Apr 2009 15:45:49 +0200	[thread overview]
Message-ID: <200904061545.49558.Christoph.Egger@amd.com> (raw)
In-Reply-To: <d15b2c7b0904060611v504df7b5g4ecaaa8bef7fe12f@mail.gmail.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

  reply	other threads:[~2009-04-06 13:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 13:11 A question about SYSENTER/SYSEXIT in HVM guest Guofu Xiang
2009-04-06 13:45 ` Christoph Egger [this message]
     [not found]   ` <d15b2c7b0904060711o1200844bof20e6eddc37f019a@mail.gmail.com>
2009-04-06 15:34     ` Christoph Egger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200904061545.49558.Christoph.Egger@amd.com \
    --to=christoph.egger@amd.com \
    --cc=whxgf1984@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.