Xen devel - May 2011 - MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

Hi, I am working on being able to determine which process owns a PTE being
changed during each MMU update in 64-bit paravirtualized mode. I have a
couple questions here.

1. When a linux DomU wants to make an update to a PTE, it calls
HYPERVISOR_mmu_update? In my case it appears to be calling MULTI_mmu_update
mostly. Are these two functions the only primary ways a VM will ask for an
MMU update?

2. The mmu_update struct that comes along with a MMU update has a *unint64_t
ptr*  which is a machine address to the PTE being changed. Is there any way
to use this machine address and determine the pte_t or page from within a
DomU?

Thanks for any help you can give!

Chris Benninger


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 05/12/2011 03:41 PM, chrisbenninger wrote:
> Hi, I am working on being able to determine which process owns a PTE
> being changed during each MMU update in 64-bit paravirtualized mode. I
> have a couple questions here.
>
> 1. When a linux DomU wants to make an update to a PTE, it calls
> HYPERVISOR_mmu_update? In my case it appears to be calling
> MULTI_mmu_update mostly. Are these two functions the only primary ways
> a VM will ask for an MMU update?
There''s also update_va_mapping and direct writes to the pte which are
trapped and emulated.  However, I''ve got patches to drop the use of
update_va_mapping in pvops Linux, at least.
> 2. The mmu_update struct that comes along with a MMU update has a
> /unint64_t ptr/  which is a machine address to the PTE being changed.
> Is there any way to use this machine address and determine the pte_t
> or page from within a DomU?
>From within domU?  You could convert it back into a pseudo-phys address
and get the pfn, but its hard to connect a random pte page to a virtual
address or even connect it to an address space.

What are you trying to achieve?  Most usermode pte updates will be to
the current process.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

Chris Benninger

University of Victoria, Computer Science
cbenning@cs.uvic.ca
http://benninger.ca



On Tue, May 17, 2011 at 10:29 PM, Jeremy Fitzhardinge
<jeremy@goop.org>wrote:
> On 05/12/2011 03:41 PM, chrisbenninger wrote:
> > Hi, I am working on being able to determine which process owns a PTE
> > being changed during each MMU update in 64-bit paravirtualized mode. I
> > have a couple questions here.
> >
> > 1. When a linux DomU wants to make an update to a PTE, it calls
> > HYPERVISOR_mmu_update? In my case it appears to be calling
> > MULTI_mmu_update mostly. Are these two functions the only primary ways
> > a VM will ask for an MMU update?
>
> There''s also update_va_mapping and direct writes to the pte which
are
> trapped and emulated.  However, I''ve got patches to drop the use
of
> update_va_mapping in pvops Linux, at least.
>
> > 2. The mmu_update struct that comes along with a MMU update has a
> > /unint64_t ptr/  which is a machine address to the PTE being changed.
> > Is there any way to use this machine address and determine the pte_t
> > or page from within a DomU?
>
> From within domU?  You could convert it back into a pseudo-phys address
> and get the pfn, but its hard to connect a random pte page to a virtual
> address or even connect it to an address space.
>
> What are you trying to achieve?  Most usermode pte updates will be to
> the current process.
>
>    J
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, May 18, 2011 at 1:25 PM, Christopher Benninger
<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.


-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

Interesting,

Are you talking about when DomU calls setpte?

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

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
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel