MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[chrisbenninger]

[-- Attachment #1.1: Type: text/plain, Size: 684 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 870 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Jeremy Fitzhardinge]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Christopher Benninger]

[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2369 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Wei Liu]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Jeremy Fitzhardinge]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Christopher Benninger]

[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1718 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: MULTI_mmu_update, HYPERVISOR_mmu_update and pte entry

[Jeremy Fitzhardinge]

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