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@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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home