WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] how page faults are handled in paravirtualized xenguests?
From: tgh <wwwwww4187@xxxxxxxxxxx>
Date: Tue, 11 Mar 2008 09:38:38 +0800
Cc: weiming <zephyr.zhao@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Daniel Stodden <stodden@xxxxxxxxxx>
Delivery-date: Mon, 10 Mar 2008 18:39:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3F9C845.1DB90%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C3F9C845.1DB90%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)
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