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

[Xen-devel] Re: [PATCH] shadow-fixes.patch

To: Michael A Fetterman <Michael.Fetterman@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] shadow-fixes.patch
From: Arun Sharma <arun.sharma@xxxxxxxxx>
Date: Mon, 30 May 2005 09:33:27 -0700
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 30 May 2005 16:32:55 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E1DcCCV-0000L7-00@xxxxxxxxxxxxxxxxx>
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: <E1DcCCV-0000L7-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
Michael A Fetterman wrote:
Re #1, below: can you provide a call stack when snapshot_entry_match faults?
Seems like it's only ever called from __shadow_out_of_sync(), and that
function
tests for possible faulting conditions before invoking
snapshot_entry_match().
I'm not sure I see how you could be seeing this.


This is what the stack trace looked like:

(XEN) EIP:    e008:[<ff125037>]
(XEN) EFLAGS: 00010246   CONTEXT: hypervisor
(XEN) eax: fefa2000   ebx: fe31b000   ecx: ffbce0e0   edx: 00000000
(XEN) esi: c0000000   edi: ffbdb080   ebp: 000000b1   esp: ff103f04
(XEN) ds: e010   es: e010   fs: e010   gs: e010   ss: e010   cs: e008
(XEN) cr0: 00000004   cr3: 00000384
(XEN) Xen stack trace from esp=ff103f04:
(XEN) 3d6e4000 00000c1b c0000000 ffbdb080 fe31b000 bff1b2c4 00000000 ffbdb080 (XEN) ffbda080 ffbcb080 c6cb1000 [ff124b20] ffbda080 c6cb1000 ffbda080 [ff12f601] (XEN) 07ccc063 00c1b063 01b05063 0000681e ffbda080 c6cb1000 ffbda080 [ff12f04d] (XEN) ffbda080 c6cb1000 00000002 ffbf7080 ffbda080 004c4b43 00000000 61402178 (XEN) bffff700 bffff6f8 bffff6d8 00000000 bffff6a0 00000001 00185000 c6cbd000 (XEN) c35e4448 00000100 c76daa84 [ff13600d] c6cbd000 ffffffff c6cbd000 c35e4448 (XEN) 00000100 c76daa84 c6cb1000 00000002 c36a5000 00130000 00000000 0000e008
(XEN)    00000202 00000010 00000010 00000000 00000000 00000000 ffbda080
(XEN) Xen call trace from esp=ff103f04:
(XEN)    [<ff124b20>] [<ff12f601>] [<ff12f04d>] [<ff13600d>]

I remember va=c6cb1000 and it was a vmexit due to invlpg -> shadow_invlpg -> __shadow_sync_va -> __shadow_out_of_sync()

I think the issue is, even though you've verified that it has a valid L2 entry, update_hl2e() hasn't been called. So linear pagetable can still fault.

        -Arun

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

<Prev in Thread] Current Thread [Next in Thread>