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] why xen use x86_emulat ion() in page_fault

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] why xen use x86_emulat ion() in page_fault
From: cc Luit <universalbillow@xxxxxxxxx>
Date: Tue, 11 Oct 2011 20:57:31 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 11 Oct 2011 05:59:44 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDCaesPGYkQBYJnS6i10+hxuqWAC+sKR6wVUfv22PJ8=; b=ooCjK7lbp6wfCXQnofa9Lf3WxBkYH7q95cR4utzdtNa0rrkj4VmS74F9C1zo+aCm6U nlTiU7rcUbCQJoi5BhX7nx0eTvPQB3+AUm7GI3028wr5qC1i0TxXJI4aeycUlmlWv7gL VeK3mXLnXuuwp0wjHDg66YDexUkkSo74MNCNw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAFLBxZZ4vqiQjGONJHKmRZqES5SJv71A9_kUkux6qjvo3407Ng@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAFLBxZbLcqpcJfFRSnT_C=5krhen44EzMD5pKcDNGhvLYmck=g@xxxxxxxxxxxxxx> <CADWh-PF1BOSN22-Ua41fuRDP9HsHJ3j=T9j7_Kc2Un8XnVMKOQ@xxxxxxxxxxxxxx> <CAFLBxZZ4vqiQjGONJHKmRZqES5SJv71A9_kUkux6qjvo3407Ng@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Tue, Oct 11, 2011 at 7:39 PM, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
On Tue, Oct 11, 2011 at 11:12 AM, cc Luit <universalbillow@xxxxxxxxx> wrote:
> Yeah, I've seen this comments, I understand what it says in the before part,
> but not the last sentence, what does it mean by "non-user write"?

> As you know, pagetables have a write-protect bit, such that writes to
> that virtual address will cause a fault.

> But there's an option in CR0 that can make the WP bit only work in
> user mode, and not kernel mode.

> So if the guest has CR0.WP clear, and the guest PTE is read-only, the
> guest needs to see this:
> 1. In user mode, writes cause a page fault
> 2. In kernel mode, writes do not cause a page fault

> But Xen needs to protect pagetables to detect changes to them.  So
> what Xen needs is this:
> 1. In user mode, writes cause a page fault to be delivered to the guest
> 2. In kernel mode, writes to non-PTs do not cause a page fault to be
> delivered to the guest
> 3. In kernel mode, writes to PTs cause a trap to xen, but do not cause
> a page fault to be delivered to the guest

> Unfortunately, there's no way to cause traps to xen in the case of #3
> without also causing traps to Xen in case #2.  So the if statement is
> designed to handle case #2.
 
> another question is that if for some reasons I want to design that the Guest
> PTE is not read-only, which means in the page_fault situation I don't want
> xen to emulate, is there any functionability or feasibility problems?

> The basic problem is that in shadow mode, changes to the guest's
> pagetables need to be propagated into the shadow pagetables.  If you
> can figure out how to make that happen without trapping to Xen and
> emulating, all the better. :-)
appreciate your explanation so much, that's really detail and helpfull!
but I think for the propagate from GPT to SPT, it's not always need the sync all the time, I know in the early version of xen there is not need to do that, but just the Lazy mode, which means (just what I understand, but not sure):
 when guest os modify the GPT, do not emulate (there is no write-protected PTE, so guest can directly modify it)
 1) when the access right ascension, the guest OS will INVLPG to shootdown TLB, so hypervisor can catch the INPLPG inst to sync  up the SPT/GPT
 2) when access right down, when guest OS access this page it will trap to xen, xen will catch #PF to sync up SPT/GPT,
 
have you ever heard of that before, I'm not sure if it is right, what's your opinion?
 
 

> thanks for your answer:)

> bu ke qi! ;-)
feel kind and amazed to see the Chinese Pinyin, really feel kind of you:-)

 -George



--
- Luit @ Parallel Processing Institute, Fudan University 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel