Re: [Xen-devel] how page faults are handled in paravirtualized xenguests?

[tgh <wwwwww4187@xxxxxxxxxxx>]

hi
 and that is ,in 64-bit,guest application entry into guestos kernel 
directly through SYSCALL,or  not?
Thnaks




Keir Fraser 写道:
> Hypercalls and syscalls are both performed using the SYSCALL 
> instruction for 64-bit guests. SYSCALL from 64-bit guest kernel 
> triggers the hypercall path; SYSCALL from 64-bit guest application 
> causes entry to 64-bit guest kernel.
>  -- Keir
>
> On 9/3/08 16:37, "weiming" <zephyr.zhao@xxxxxxxxx> wrote:
>
>     Hi Daniel & Haifeng,
>
>     Thanks for your elaboration.
>     Now I'm almost clear on this problem.
>
>     Daniel, Could you please explain why "not the case for 64-bit
>     systems."
>     For system calls, a regular OS will issure INT 0x80 to do system
>     calls. In Xen, this interrupt will be handled by the guest
>     directly. In guest OS can use 0x82 interrupt to call hypercalls.
>
>     So how is x86_64 different? I'm more interested in 64-bit system
>     because I'll work on it.
>
>     Thanks a lot!
>     Weiming
>
>
>
>     On Sun, Mar 9, 2008 at 10:33 AM, Daniel Stodden
>     <stodden@xxxxxxxxxx> wrote:
>
>         On Sun, 2008-03-09 at 10:27 +0800, 房海峰 wrote:
>         > hello, my friend:
>         >
>         > According to my research with source code of xen, i think the
>         process
>         > is that:
>         >
>         > first, when Guest OS is created by Xen/Domian0, it install
>         it's IDT
>         > through "set_trap_table" hypercall.
>         > second, during Xen/GuestOS running, all interrupt/trap will
>         result a
>         > trap into Ring0, that is the layer of Xen.
>         > for some trap, such as system-call, they will be dealt with
>         directly
>         > through interrupt hardware.
>         > For the most of other traps, they will be dealt by xen, and then
>         > dispatched to corresponding Guest OS.
>         >
>         > in addition, there are other details to study in-depth.
>
>         Generally, the IDT entry may either point to xen or directly
>         to the
>         trap handler installed by the guest.
>
>         For system calls, it presently depends on the architecture:
>         x86_32 has
>         separate trap instructions for hypercalls and system calls,
>         which can be
>         forwarded directly. But is not the case for 64-bit systems.
>
>         In fault handling, it depends on the type of fault. It may be
>         either due
>         to the virtualization layer, then transparently fixed by Xen (e.g.
>         instruction emulation). Or the guest may be responsible (e.g.
>         a process
>         page fault). In that case the fault will be forwarded.
>
>         Some faults (e.g. division by zero) are indeed never Xen's
>         business.
>         Still, you'll find the idt entry to point to xen, instead of
>         directly to
>         the ring1 kernel. See the use of DO_ERROR_*() in x86/traps.c. The
>         reason is simply that bugs in Xen (of course, that's
>         impossible :), but
>         you never know) would not be caught otherwise.
>
>         So, the bottom line is that all goes through Xen, except for
>         32-on-32
>         bit system calls.
>
>         hth,
>         daniel
>
>         --
>         Daniel Stodden
>         LRR     -      Lehrstuhl für Rechnertechnik und
>         Rechnerorganisation
>         Institut für Informatik der TU München             D-85748
>         Garching
>         http://www.lrr.in.tum.de/~stodden
>         <http://www.lrr.in.tum.de/%7Estodden>
>         <http://www.lrr.in.tum.de/%7Estodden>
>                  mailto:stodden@xxxxxxxxxx
>         PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8
>         735B
>
>
>
>
>     ------------------------------------------------------------------------
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@xxxxxxxxxxxxxxxxxxx
>     http://lists.xensource.com/xen-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel