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/
Home Products Support Community News


答复: 答复: [Xen-devel] About TSSinitialization when Xen booting.

To: "'Ian Campbell'" <Ian.Campbell@xxxxxxxxxxxxx>
Subject: 答复: 答复: [Xen-devel] About TSSinitialization when Xen booting.
From: 李亚琼 <liyaq04@xxxxxxxxxx>
Date: Tue, 7 Aug 2007 15:20:52 +0800
Cc: "'Li, Xin B'" <xin.b.li@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Aug 2007 00:18:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1186469557.6686.5.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfYvf5JTXTgZZgUTIq3XJXICk2efgAAi6xw
        I know what you mean. But the problem is that guest_cpu_user_regs.es
(the macro of get_frame_bottom() returns this value) is used to initialize
the TSS when it has not been initialized. If TSS has not been initialized
correctly, Xen can't switch to the kernel stack of the current cpu when a
interrupt or trap occurs. Tss initialization should correctly be initialized
before a interrupt or trap occurs. But I can't find where
guest_cpu_user_regs.es is initialized before used to initialize TSS in
function percpu_traps_init().
        Hope your reply!


发件人: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx] 
发送时间: 2007年8月7日 14:53
收件人: 李亚琼
抄送: 'Li, Xin B'; 
主题: Re: 答复: [Xen-devel] About TSSinitialization when Xen booting.

On Tue, 2007-08-07 at 09:27 +0800, 李亚琼 wrote:
> Thanks, Xin!
> But __context_switch will be invoked only when system is scheduled.
> During the initialization, Xen invokes percpu_traps_init and cpu_init
> to initialize a physical cpu. In this two functions, tss will be
> assigned with a value from guest_cpu_user_regs. But till this time,
> __context_switch has never been invoked. In other words, idle_domain’s
> tss is assigned with a trivial value. After all, when Xen is in the
> idle domain, a stack switch will occur when a interrupt occurs. Is it
> correct?

get_cpu_info returns a pointer into the stack. guest_cpu_user_regs is a
member of the structure this pointer points to (but not a pointer
itself). It has been arranged so that guest_cpu_user_regs overlaps the
part of the stack where entry.S will save the guests registers (mainly
in the SAVE_ALL macro).

This should make sense because the TSS is being initialised with exactly
the value you wish the stack to have when transitioning to ring0.

> The question is about the variables,  “stack”  and “stack_bottom”. At
> this moment, if guest_cpu_user_regs has not been initialized,
> “stack_bottom” will be zero when the cpu is the first physical cpu
> ( its stack is initialized with zero in file boot.S). And then “stack”
> will be zero, too. Is it correct?

Remember that guest_cpu_user_regs isn't a pointer, it's just a member of
a struct so it's address will currently be the address of that struct
plus an offset.


Xen-devel mailing list