From mboxrd@z Thu Jan  1 00:00:00 1970
From: Arun Sharma <arun.sharma@intel.com>
Subject: Re: [PATCH] shadow-fixes.patch
Date: Mon, 30 May 2005 09:33:27 -0700
Message-ID: <429B4057.7030500@intel.com>
References: <E1DcCCV-0000L7-00@mta1.cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <E1DcCCV-0000L7-00@mta1.cl.cam.ac.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Michael A Fetterman <Michael.Fetterman@cl.cam.ac.uk>
Cc: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

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