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


Re: [Xen-devel] MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

To: Christopher Benninger <chrisbenninger@xxxxxxxxx>
Subject: Re: [Xen-devel] MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 19 May 2011 10:49:51 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Wei Liu <liuw@xxxxxxxxx>
Delivery-date: Thu, 19 May 2011 18:01:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTikc6uumHUicraZp4TH51=Jz7_Ry2g@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: <BANLkTim1p6W=zq9MDoU+xkmrR2xvapQ4mA@xxxxxxxxxxxxxx> <4DD2F6B1.5080208@xxxxxxxx> <BANLkTim4JrTUK5itYNqts4XPzTXma4Z=6A@xxxxxxxxxxxxxx> <BANLkTimQMJ4MceFvJ+yMxuCa7Tdt_qdtEA@xxxxxxxxxxxxxx> <1305706199.4198.0.camel@xxxxxxxxxxxxxxxxx> <BANLkTikc6uumHUicraZp4TH51=Jz7_Ry2g@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
On 05/19/2011 10:37 AM, Christopher Benninger wrote:
> Interesting,
> Are you talking about when DomU calls setpte?

Within Linux, "current" always evaluates to the current task.  It would
be a bit dubious to use it from within an async interrupt context, but I
don't think usermode ptes can ever be meaningfully updated in that context.

Pagetable updates to the kernel part of the address space have a
different set of rules, so you'll need to either ignore them or cope
with them in some way.  And I'm sure there are some cases where there
could be cross-address space updates, though I can't think of them off
hand (ptrace, perhaps?).

BTW, most usermode updates are done with set_pte_at rather than bare
set_pte, so you get the vaddr along with it.


> Chris Benninger
> University of Victoria, Computer Science
> cbenning@xxxxxxxxxx <mailto:cbenning@xxxxxxxxxx>
> http://benninger.ca <http://benninger.ca/>
> On Wed, May 18, 2011 at 1:09 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx
> <mailto:jeremy@xxxxxxxx>> wrote:
>     On Wed, 2011-05-18 at 13:47 +0800, Wei Liu wrote:
>     > On Wed, May 18, 2011 at 1:25 PM, Christopher Benninger
>     > <chrisbenninger@xxxxxxxxx <mailto:chrisbenninger@xxxxxxxxx>> wrote:
>     > > Hi Jeremy,
>     > > I am definitely doing something weird, but on purpose. I am
>     trying to
>     > > determine which process specifically owns the pte in question.
>     I have a domU
>     > > module which I can ask for information, I just dont know how
>     to get the ptr
>     > > provided, into a useful context I can send it.
>     >
>     > Most pte updates belong to current process. Maybe you can use CR3 to
>     > determine to which page table a specified pte belongs. But it may be
>     > hard to determine the actual task_struct IMHO.
>     If you can record it at the time of the setpte, its easy: "current" is
>     always the current task.
>            J

Xen-devel mailing list