From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry Date: Thu, 19 May 2011 10:49:51 -0700 Message-ID: <4DD5583F.5060506@goop.org> References: <4DD2F6B1.5080208@goop.org> <1305706199.4198.0.camel@abulafia.goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christopher Benninger Cc: xen-devel@lists.xensource.com, Wei Liu List-Id: xen-devel@lists.xenproject.org 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. J > > Chris Benninger > > University of Victoria, Computer Science > cbenning@cs.uvic.ca > http://benninger.ca > > > > On Wed, May 18, 2011 at 1:09 AM, Jeremy Fitzhardinge > wrote: > > On Wed, 2011-05-18 at 13:47 +0800, Wei Liu wrote: > > On Wed, May 18, 2011 at 1:25 PM, Christopher Benninger > > > 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 > > >