Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Jeremy Fitzhardinge <jeremy@goop.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 <mailto:cbenning@cs.uvic.ca>
> http://benninger.ca <http://benninger.ca/>
>
>
>
> On Wed, May 18, 2011 at 1:09 AM, Jeremy Fitzhardinge <jeremy@goop.org
> <mailto:jeremy@goop.org>> 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@gmail.com <mailto:chrisbenninger@gmail.com>> 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
>
>
>