page table question!

page table question!

[MT Rezaie]

I want to know any difference between writing, reading and shadow page
table (for example performance).
I am thankful for any help or resource for that.

-- 
Best Regards
Mohamad Taghi Mir Mohamad Rezaie

Iran University of Science and Technology
Department of Computer Science & Engineering
System Software Group

RE: page table question!

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie
> Sent: 13 June 2007 15:55
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] page table question!
> 
> I want to know any difference between writing, reading and shadow page
> table (for example performance).

Not sure exactly what you're asking for: are you asking about "writable"
and "non-writable" page-table vs. shadow-page-table?

I believe "writable" page-table means that the guest is able to write
DIRECTLY to the lower level(s) of the page-table, and as such, we
"trust" the guest to do this correctly (and not map in stuff that
doesn't belong to the guest). I believe this mode isn't normally used by
Xen guests. This mode relies on the guest to correctly translate the
guest-physical address to a machine physical address. 

Non-writable page-tables are mapped "read-only" throughout the entire
page-table, and when a write occurs, the page-table is updated via the
emulation of the instruction in the hypervisor. The hypervisor can check
that the machine physical address is correct for the particular guest. 

As of currently, Shadow-mode is only used for HVM (fully virtualized)
domains. In this case, the guest has a "dummy" page-table that is not
used by the processor for any memory accesses, instead a "shadow" (copy)
of the guest's page-table is used. The shadow page-table is used by the
processor. To make updates to the page-table appear in the
shadow-page-table, the hypervisor is making sure that the
guest-page-table is read-only, and when the guest writes to the
page-table, we reproduce the write [with modification to reflect the
difference between guest physical and machine physical address].

--
Mats

> I am thankful for any help or resource for that.
> 
> -- 
> Best Regards
> Mohamad Taghi Mir Mohamad Rezaie
> 
> Iran University of Science and Technology
> Department of Computer Science & Engineering
> System Software Group
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

Re: page table question!

[Mark Williamson]

> > I want to know any difference between writing, reading and shadow page
> > table (for example performance).
>
> Not sure exactly what you're asking for: are you asking about "writable"
> and "non-writable" page-table vs. shadow-page-table?

"Writable pagetables" is an interface introduced for Xen 3 PV guests to update 
their pagetables.  Previous versions of Xen required guests to be modified to 
make every update to their pagetables explicitly call into Xen (and 
explicitly batch those operations).  Writeable pagetables replace this by 
allowing updates to the pagetables to be implemented by the guest as attempts 
to write directly to them.  This isn't a trusted operation, however, since 
Xen uses page protections to prevent unvalidated writes going through...  
Right now this is implemented by trapping each attempt to write to the lower 
levels of the pagetables and emulating it in Xen.  Previous implementations 
were a bit more complicated but found to be unnecessary.

This interface does require the guest to do physical->machine translations 
(which are verified by Xen before installing them), and the guest actually 
works with the real pagetables (subject to certain restrictions).  As a 
result the guest can get data out of the real pagetables by doing a simple 
read - this operation should be as fast as native.  Updating pagetables is 
obviously a bit slower than native because Xen has to emulate them; explicit 
calls to Xen's batched update interface are used to give decent performance 
when lots of PTEs are being modified.

Does that answer your question, Mohammad?

> As of currently, Shadow-mode is only used for HVM (fully virtualized)
> domains. In this case, the guest has a "dummy" page-table that is not
> used by the processor for any memory accesses, instead a "shadow" (copy)
> of the guest's page-table is used. The shadow page-table is used by the
> processor. To make updates to the page-table appear in the
> shadow-page-table, the hypervisor is making sure that the
> guest-page-table is read-only, and when the guest writes to the
> page-table, we reproduce the write [with modification to reflect the
> difference between guest physical and machine physical address].

What Mats said :-)

One thing I've never been clear on for shadow mode is how accessed / dirty 
bits get propagated to the guest pagetable from the shadow.

At some point there was also support in Xen for fully translated shadowing of 
PV guests but I'm not sure this works now.  PV guests do still get shadowed 
in a limited way during live migration, however.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

RE: page table question!

[Petersson, Mats]

 

> -----Original Message-----
> From: M.A. Williamson [mailto:maw48@hermes.cam.ac.uk] On 
> Behalf Of Mark Williamson
> Sent: 13 June 2007 17:06
> To: xen-devel@lists.xensource.com
> Cc: Petersson, Mats; MT Rezaie
> Subject: Re: [Xen-devel] page table question!
> 
> > > I want to know any difference between writing, reading 
> and shadow page
> > > table (for example performance).
> >
> > Not sure exactly what you're asking for: are you asking 
> about "writable"
> > and "non-writable" page-table vs. shadow-page-table?
> 
> "Writable pagetables" is an interface introduced for Xen 3 PV 
> guests to update 
> their pagetables.  Previous versions of Xen required guests 
> to be modified to 
> make every update to their pagetables explicitly call into Xen (and 
> explicitly batch those operations).  Writeable pagetables 
> replace this by 
> allowing updates to the pagetables to be implemented by the 
> guest as attempts 
> to write directly to them.  This isn't a trusted operation, 
> however, since 
> Xen uses page protections to prevent unvalidated writes going 
> through...  
> Right now this is implemented by trapping each attempt to 
> write to the lower 
> levels of the pagetables and emulating it in Xen.  Previous 
> implementations 
> were a bit more complicated but found to be unnecessary.

Thanks for clarifying. I seem to remember reading about a mode where the
page-table isn't "read-only" - did I just imagine that, or what?
> 
> This interface does require the guest to do physical->machine 
> translations 
> (which are verified by Xen before installing them), and the 
> guest actually 
> works with the real pagetables (subject to certain 
> restrictions).  As a 
> result the guest can get data out of the real pagetables by 
> doing a simple 
> read - this operation should be as fast as native.  Updating 
> pagetables is 
> obviously a bit slower than native because Xen has to emulate 
> them; explicit 
> calls to Xen's batched update interface are used to give 
> decent performance 
> when lots of PTEs are being modified.
> 
> Does that answer your question, Mohammad?
> 
> > As of currently, Shadow-mode is only used for HVM (fully 
> virtualized)
> > domains. In this case, the guest has a "dummy" page-table 
> that is not
> > used by the processor for any memory accesses, instead a 
> "shadow" (copy)
> > of the guest's page-table is used. The shadow page-table is 
> used by the
> > processor. To make updates to the page-table appear in the
> > shadow-page-table, the hypervisor is making sure that the
> > guest-page-table is read-only, and when the guest writes to the
> > page-table, we reproduce the write [with modification to reflect the
> > difference between guest physical and machine physical address].
> 
> What Mats said :-)

There is another mode that we haven't mentioned yet, which is the
HAP-mode (aka NPT (Nested Page-tables) from AMD, and Intel has something
similar which I believe is called EPT). HAP stands for Hardware Assisted
Paging. This mode is (obviously) only available in processors that have
support for this feature - there are none of these available on the
market just yet.

The idea in this mode is that the guest doesn't know about the
machine-physical address, but we also don't intercept page-table writes
(by making the guest page-table read-only). Instead, there is a second,
hypervisor-owned, page-table that translates the guest-physical address
to machine-physical address. 

So instead of using a single page-table that is "modified" to match the
guest-virtual->machine-physical, we add another layer of page-table to
translate guest-physical->machine-physical address. This second
page-table is normally static, so it requires no changes under normal
operation. 

There is a performance advantage here in that we don't have to intercept
the write to the page-table. This is normally fairly expensive, so for
systems where page-tables are written often, it's definitely worth
having. On systems with rare updates to the page-table, the performance
advantage is much smaller, if any at all. 

> 
> One thing I've never been clear on for shadow mode is how 
> accessed / dirty 
> bits get propagated to the guest pagetable from the shadow.

Good question. I have a feeling that the answer is "it doesn't". HAP
would probably solve this problem. 

--
Mats

> 
> At some point there was also support in Xen for fully 
> translated shadowing of 
> PV guests but I'm not sure this works now.  PV guests do 
> still get shadowed 
> in a limited way during live migration, however.
> 
> Cheers,
> Mark
> 
> -- 
> Dave: Just a question. What use is a unicyle with no seat?  
> And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
> 
> 
> 

Re: page table question!

[Mark Williamson]

> > "Writable pagetables" is an interface introduced for Xen 3 PV
> > guests to update
> > their pagetables.  Previous versions of Xen required guests
> > to be modified to
> > make every update to their pagetables explicitly call into Xen (and
> > explicitly batch those operations).  Writeable pagetables
> > replace this by
> > allowing updates to the pagetables to be implemented by the
> > guest as attempts
> > to write directly to them.  This isn't a trusted operation,
> > however, since
> > Xen uses page protections to prevent unvalidated writes going
> > through...
> > Right now this is implemented by trapping each attempt to
> > write to the lower
> > levels of the pagetables and emulating it in Xen.  Previous
> > implementations
> > were a bit more complicated but found to be unnecessary.
>
> Thanks for clarifying. I seem to remember reading about a mode where the
> page-table isn't "read-only" - did I just imagine that, or what?

As far as I know normal Xen doesn't support any mode where the guest can write 
directly to real pagetables without validation... 

I can think of two things you might have read about:

1) on intercepting an attempted write to an L1 pagetable, the wrpt code would 
unhook that from the pagetable hierarchy, and then make it writable.  
Subsequently, the guest could write to it as a normal page.  A fault would 
occur if the CPU tried to translate a VA covered by this pagetable, at which 
point Xen would revalidate that pagetable for safety, then hook it back into 
the hierarchy.  This let batching of pagetable updates be entirely implicit, 
but it later turned out that it performed less well than emulating each 
write, and using explicit batching in the guest.

2) if you compile Xen with the right options, a dom0 kernel (possibly with the 
right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen's 
normal checks.  The intent was to use this to make a kernel bootable both on 
native hardware (eventually using a "minixen" rather than heavyweight Xen) 
and paravirt.  This hasn't been investigated much, since Linux decided to 
pursue the paravirt-ops solution, which allows a kernel to boot native or 
paravirt anyway.


> > One thing I've never been clear on for shadow mode is how
> > accessed / dirty
> > bits get propagated to the guest pagetable from the shadow.
>
> Good question. I have a feeling that the answer is "it doesn't". HAP
> would probably solve this problem.

Don't guests need the dirty bits for their memory management (e.g. mmap) to 
work correctly?  Maybe one could do something scary like trapping reads to 
guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross 
though.

HAP is definitely HAPpier :-)

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: page table question!

[Jun Koi]

Yesterday I committed a silly mistake, and then I went on hanging
myself as I said in my last mail. I went to heaven, and fortunately
they have internet/email here. Indeed!

The God asks me to thank people like Mats, Mark, Anthony Liguori,...
who are always willing to answer technical questions on the list. It
is believed that not everybody can explain problems in clear and
easy-to-understand way like you can do. Your posts are always very
much useful, and I believe that those helps can raise and attract a
lot more developers for this project.

You dont know how much the community appreciate your helps! Thanks god
we have people like you here!

Keep posting, and you will all go to heaven :-)

>From heaven, with respects,
Jun


On 6/14/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > > "Writable pagetables" is an interface introduced for Xen 3 PV
> > > guests to update
> > > their pagetables.  Previous versions of Xen required guests
> > > to be modified to
> > > make every update to their pagetables explicitly call into Xen (and
> > > explicitly batch those operations).  Writeable pagetables
> > > replace this by
> > > allowing updates to the pagetables to be implemented by the
> > > guest as attempts
> > > to write directly to them.  This isn't a trusted operation,
> > > however, since
> > > Xen uses page protections to prevent unvalidated writes going
> > > through...
> > > Right now this is implemented by trapping each attempt to
> > > write to the lower
> > > levels of the pagetables and emulating it in Xen.  Previous
> > > implementations
> > > were a bit more complicated but found to be unnecessary.
> >
> > Thanks for clarifying. I seem to remember reading about a mode where the
> > page-table isn't "read-only" - did I just imagine that, or what?
>
> As far as I know normal Xen doesn't support any mode where the guest can write
> directly to real pagetables without validation...
>
> I can think of two things you might have read about:
>
> 1) on intercepting an attempted write to an L1 pagetable, the wrpt code would
> unhook that from the pagetable hierarchy, and then make it writable.
> Subsequently, the guest could write to it as a normal page.  A fault would
> occur if the CPU tried to translate a VA covered by this pagetable, at which
> point Xen would revalidate that pagetable for safety, then hook it back into
> the hierarchy.  This let batching of pagetable updates be entirely implicit,
> but it later turned out that it performed less well than emulating each
> write, and using explicit batching in the guest.
>
> 2) if you compile Xen with the right options, a dom0 kernel (possibly with the
> right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen's
> normal checks.  The intent was to use this to make a kernel bootable both on
> native hardware (eventually using a "minixen" rather than heavyweight Xen)
> and paravirt.  This hasn't been investigated much, since Linux decided to
> pursue the paravirt-ops solution, which allows a kernel to boot native or
> paravirt anyway.
>
>
> > > One thing I've never been clear on for shadow mode is how
> > > accessed / dirty
> > > bits get propagated to the guest pagetable from the shadow.
> >
> > Good question. I have a feeling that the answer is "it doesn't". HAP
> > would probably solve this problem.
>
> Don't guests need the dirty bits for their memory management (e.g. mmap) to
> work correctly?  Maybe one could do something scary like trapping reads to
> guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross
> though.
>
> HAP is definitely HAPpier :-)
>
> Cheers,
> Mark
>
> --
> Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: page table question!

[pradeep singh rautela]

On 6/14/07, Jun Koi <junkoi2004@gmail.com> wrote:
> Yesterday I committed a silly mistake, and then I went on hanging
> myself as I said in my last mail. I went to heaven, and fortunately
> they have internet/email here. Indeed!
>
> The God asks me to thank people like Mats, Mark, Anthony Liguori,...
> who are always willing to answer technical questions on the list. It
> is believed that not everybody can explain problems in clear and
> easy-to-understand way like you can do. Your posts are always very
> much useful, and I believe that those helps can raise and attract a
> lot more developers for this project.
>
> You dont know how much the community appreciate your helps! Thanks god
> we have people like you here!
>
> Keep posting, and you will all go to heaven :-)
Actually this keep posting ,and you will go to heaven part is luring
enough :-).Even for people like me who want to contribute and now one
more reason to stick to Xen;).

Good one Jun.
(I hope they'll let my message in)
Regards
--psr

>
> >From heaven, with respects,
> Jun
>
>
> On 6/14/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > > > "Writable pagetables" is an interface introduced for Xen 3 PV
> > > > guests to update
> > > > their pagetables.  Previous versions of Xen required guests
> > > > to be modified to
> > > > make every update to their pagetables explicitly call into Xen (and
> > > > explicitly batch those operations).  Writeable pagetables
> > > > replace this by
> > > > allowing updates to the pagetables to be implemented by the
> > > > guest as attempts
> > > > to write directly to them.  This isn't a trusted operation,
> > > > however, since
> > > > Xen uses page protections to prevent unvalidated writes going
> > > > through...
> > > > Right now this is implemented by trapping each attempt to
> > > > write to the lower
> > > > levels of the pagetables and emulating it in Xen.  Previous
> > > > implementations
> > > > were a bit more complicated but found to be unnecessary.
> > >
> > > Thanks for clarifying. I seem to remember reading about a mode where the
> > > page-table isn't "read-only" - did I just imagine that, or what?
> >
> > As far as I know normal Xen doesn't support any mode where the guest can write
> > directly to real pagetables without validation...
> >
> > I can think of two things you might have read about:
> >
> > 1) on intercepting an attempted write to an L1 pagetable, the wrpt code would
> > unhook that from the pagetable hierarchy, and then make it writable.
> > Subsequently, the guest could write to it as a normal page.  A fault would
> > occur if the CPU tried to translate a VA covered by this pagetable, at which
> > point Xen would revalidate that pagetable for safety, then hook it back into
> > the hierarchy.  This let batching of pagetable updates be entirely implicit,
> > but it later turned out that it performed less well than emulating each
> > write, and using explicit batching in the guest.
> >
> > 2) if you compile Xen with the right options, a dom0 kernel (possibly with the
> > right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen's
> > normal checks.  The intent was to use this to make a kernel bootable both on
> > native hardware (eventually using a "minixen" rather than heavyweight Xen)
> > and paravirt.  This hasn't been investigated much, since Linux decided to
> > pursue the paravirt-ops solution, which allows a kernel to boot native or
> > paravirt anyway.
> >
> >
> > > > One thing I've never been clear on for shadow mode is how
> > > > accessed / dirty
> > > > bits get propagated to the guest pagetable from the shadow.
> > >
> > > Good question. I have a feeling that the answer is "it doesn't". HAP
> > > would probably solve this problem.
> >
> > Don't guests need the dirty bits for their memory management (e.g. mmap) to
> > work correctly?  Maybe one could do something scary like trapping reads to
> > guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross
> > though.
> >
> > HAP is definitely HAPpier :-)
> >
> > Cheers,
> > Mark
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
> > Mark: To answer a question with a question: What use is a skateboard?
> > Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---
pradeep singh rautela

"Genius is 1% inspiration, and 99% perspiration" - not me :)

Re: page table question!

[Tim Deegan]

At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:
> > > One thing I've never been clear on for shadow mode is how
> > > accessed / dirty
> > > bits get propagated to the guest pagetable from the shadow.
> >
> > Good question. I have a feeling that the answer is "it doesn't". HAP
> > would probably solve this problem.

When a guest pagetable entry has the Accessed bit clear, its shadow has
the Present bit clear.  This means we will get an extra page fault when
the guest tries to read that area of memory.  In the page-fault handler
we write the Accessed bit into the guest entry, and replace the shadow
entry with one that has the Present bit.  A similar scheme (shadowing
~Dirty with ~Writeable) applies to those entries that have Dirty bits.

The actual moving parts are in the _sh_propagate() function in
arch/x86/mm/shadow/multi.c, which is why that function needs to be told
whether it's handling a read fault, write fault or prefetch operation.

> Don't guests need the dirty bits for their memory management (e.g. mmap) to 
> work correctly? 

Yes, although in fact Xen doesn't quite catch all the cases where those
bits should be set (certain Xen-handled operations that walk the guest
pagetables instead of using the shadows) and it's not tripped us up
yet. :)

> Maybe one could do something scary like trapping reads to 
> guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross 
> though.

It was considered. :)  (For good reasons; talk to Michael Fetterman
some time.)

> HAP is definitely HAPpier :-)

Yep, should see a significant performance increase and eliminate a lot
of moving parts.

Tim.

-- 
Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

Re: page table question!

[tgh]

hi
In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a 
counterpart pagetable for each of the guestOS process's page table, is 
it ? then there will not be a small mount of memory consumption for 
hyperviser's limited VA ,is it? or where are those counterpart page 
tables stored ?

Thanks in advance




Tim Deegan 写道:
> At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:
>   
>>>> One thing I've never been clear on for shadow mode is how
>>>> accessed / dirty
>>>> bits get propagated to the guest pagetable from the shadow.
>>>>         
>>> Good question. I have a feeling that the answer is "it doesn't". HAP
>>> would probably solve this problem.
>>>       
>
> When a guest pagetable entry has the Accessed bit clear, its shadow has
> the Present bit clear.  This means we will get an extra page fault when
> the guest tries to read that area of memory.  In the page-fault handler
> we write the Accessed bit into the guest entry, and replace the shadow
> entry with one that has the Present bit.  A similar scheme (shadowing
> ~Dirty with ~Writeable) applies to those entries that have Dirty bits.
>
> The actual moving parts are in the _sh_propagate() function in
> arch/x86/mm/shadow/multi.c, which is why that function needs to be told
> whether it's handling a read fault, write fault or prefetch operation.
>
>   
>> Don't guests need the dirty bits for their memory management (e.g. mmap) to 
>> work correctly? 
>>     
>
> Yes, although in fact Xen doesn't quite catch all the cases where those
> bits should be set (certain Xen-handled operations that walk the guest
> pagetables instead of using the shadows) and it's not tripped us up
> yet. :)
>
>   
>> Maybe one could do something scary like trapping reads to 
>> guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross 
>> though.
>>     
>
> It was considered. :)  (For good reasons; talk to Michael Fetterman
> some time.)
>
>   
>> HAP is definitely HAPpier :-)
>>     
>
> Yep, should see a significant performance increase and eliminate a lot
> of moving parts.
>
> Tim.
>
>   

Re: page table question!

[Mark Williamson]

> In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a
> counterpart pagetable for each of the guestOS process's page table, is
> it ? then there will not be a small mount of memory consumption for
> hyperviser's limited VA ,is it? or where are those counterpart page
> tables stored ?

As far as I know, the VMM only needs one extra table per guest, not per 
process.  This describes the "guest physical" -> "machine physical" mapping.  
Guest virtual addresses are then translated by walking the guest pagetable 
(guest virtual -> guest physical) and then the physical->machine table for 
that guest (maintained by the VMM) to get a real host address.

Cheers,
Mark

> Thanks in advance
>
> Tim Deegan 写道:
> > At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:
> >>>> One thing I've never been clear on for shadow mode is how
> >>>> accessed / dirty
> >>>> bits get propagated to the guest pagetable from the shadow.
> >>>
> >>> Good question. I have a feeling that the answer is "it doesn't". HAP
> >>> would probably solve this problem.
> >
> > When a guest pagetable entry has the Accessed bit clear, its shadow has
> > the Present bit clear.  This means we will get an extra page fault when
> > the guest tries to read that area of memory.  In the page-fault handler
> > we write the Accessed bit into the guest entry, and replace the shadow
> > entry with one that has the Present bit.  A similar scheme (shadowing
> > ~Dirty with ~Writeable) applies to those entries that have Dirty bits.
> >
> > The actual moving parts are in the _sh_propagate() function in
> > arch/x86/mm/shadow/multi.c, which is why that function needs to be told
> > whether it's handling a read fault, write fault or prefetch operation.
> >
> >> Don't guests need the dirty bits for their memory management (e.g. mmap)
> >> to work correctly?
> >
> > Yes, although in fact Xen doesn't quite catch all the cases where those
> > bits should be set (certain Xen-handled operations that walk the guest
> > pagetables instead of using the shadows) and it's not tripped us up
> > yet. :)
> >
> >> Maybe one could do something scary like trapping reads to
> >> guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross
> >> though.
> >
> > It was considered. :)  (For good reasons; talk to Michael Fetterman
> > some time.)
> >
> >> HAP is definitely HAPpier :-)
> >
> > Yep, should see a significant performance increase and eliminate a lot
> > of moving parts.
> >
> > Tim.



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: page table question!

[Daniel Stodden]

On Sat, 2007-12-08 at 22:26 +0800, tgh wrote:
> hi
> In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a 
> counterpart pagetable for each of the guestOS process's page table, is 
> it ? 

No. 

It's similar to shadow paging in that two different sets of page tables
are in use. But then, returning to some of your original questions above
in this thread: *This* is where hardware consults a P2M table: The
nested page table does not, like a shadow table, translate virtual to
machine, but pseudo-physical to machine addresses.

> then there will not be a small mount of memory consumption for 
> hyperviser's limited VA ,is it? or where are those counterpart page 
> tables stored ?

Or do you mean the part of the VM dedicated to the hypervisor? Code
running in root mode is running in "host linear" address space, i.e. the
nested page table, not the guest's one. Actually, that's one major
benefit of nested paging: counteraction "address space compression".

So, the guest system takes two levels of translation, while the host
(Xen, in this case) takes only one.

Hope this helps. Clarify your question if it doesn't.

regards,
daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Re: page table question!

[tgh]

some issues are still confuesed ,

Daniel Stodden 写道:
>   
>> then there will not be a small mount of memory consumption for 
>> hyperviser's limited VA ,is it? or where are those counterpart page 
>> tables stored ?
>>     
>
> Or do you mean the part of the VM dedicated to the hypervisor? Code
> running in root mode is running in "host linear" address space, i.e. the
> nested page table, not the guest's one. Actually, that's one major
> benefit of nested paging: counteraction "address space compression".
>   
nested page table ,for the AMD NPT ,is stored in the dom0 linear space, 
not in the hypervisor virtual address ,is it? or what is the meaning of 
"that's one major benefit of nested paging: counteraction "address space 
compression".",and what about the Intel EPT, is it similar ,or how does 
it work, I am still comfused about the hypervisor' limited virtual 
address space, it wont be used for storing the EPT or NPT, is it? or 
what about  the hypervisor's virtual address space in the AMD or 
Intel-vt?how much space is it? or what is tricks behind, could you give 
me a more detailed explanation about NPT and EPT

another one ,"the guest system takes two levels of translation, while 
the host(Xen, in this case) takes only one" , what is the meaning? guest 
does virtual->physical, while physical->machine is translated by xen, is 
it? what is the tricks, by say, guest takes two levels of translation?


Thanks in advance

> So, the guest system takes two levels of translation, while the host
> (Xen, in this case) takes only one.
>
> Hope this helps. Clarify your question if it doesn't.
>
> regards,
> daniel
>
>   

Re: page table question!

[Tim Deegan]

At 11:07 +0800 on 16 Dec (1197803269), tgh wrote:
> nested page table ,for the AMD NPT ,is stored in the dom0 linear space, 
> not in the hypervisor virtual address ,is it? or what is the meaning of 
> "that's one major benefit of nested paging: counteraction "address space 
> compression".",and what about the Intel EPT, is it similar ,or how does 
> it work, I am still comfused about the hypervisor' limited virtual 
> address space, it wont be used for storing the EPT or NPT, is it? or 
> what about  the hypervisor's virtual address space in the AMD or 
> Intel-vt?how much space is it? or what is tricks behind, could you give 
> me a more detailed explanation about NPT and EPT

NPT is described in volume 2 of AMD's Architecture Programmer's Manual.
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html

I don't know of any publically available documentation on EPT, but there
are some details in Jun Nakajima's slides from the recent Xen Summit.
http://xen.org/xensummit/xensummit_fall_2007.html

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems.
[Company #5334508: XenSource UK Ltd, reg'd c/o EC2Y 5EB, UK.]

Re: page table question!

[tgh]

hi
I try to read the paging part code of xen-3.1.0, and I am confused about 
the " compat_machine_to_phys_mapping" ,what does xen do with the 
"CONFIG_COMPAT",and what are the differences between the 
"machine_to_phys_mapping" and the "compat_machine_to_phys_mapping"?

Could you help me
Thanks in advance


Petersson, Mats 写道:
>  
>
>   
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie
>> Sent: 13 June 2007 15:55
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] page table question!
>>
>> I want to know any difference between writing, reading and shadow page
>> table (for example performance).
>>     
>
> Not sure exactly what you're asking for: are you asking about "writable"
> and "non-writable" page-table vs. shadow-page-table?
>
> I believe "writable" page-table means that the guest is able to write
> DIRECTLY to the lower level(s) of the page-table, and as such, we
> "trust" the guest to do this correctly (and not map in stuff that
> doesn't belong to the guest). I believe this mode isn't normally used by
> Xen guests. This mode relies on the guest to correctly translate the
> guest-physical address to a machine physical address. 
>
> Non-writable page-tables are mapped "read-only" throughout the entire
> page-table, and when a write occurs, the page-table is updated via the
> emulation of the instruction in the hypervisor. The hypervisor can check
> that the machine physical address is correct for the particular guest. 
>
> As of currently, Shadow-mode is only used for HVM (fully virtualized)
> domains. In this case, the guest has a "dummy" page-table that is not
> used by the processor for any memory accesses, instead a "shadow" (copy)
> of the guest's page-table is used. The shadow page-table is used by the
> processor. To make updates to the page-table appear in the
> shadow-page-table, the hypervisor is making sure that the
> guest-page-table is read-only, and when the guest writes to the
> page-table, we reproduce the write [with modification to reflect the
> difference between guest physical and machine physical address].
>
> --
> Mats
>
>   
>> I am thankful for any help or resource for that.
>>
>> -- 
>> Best Regards
>> Mohamad Taghi Mir Mohamad Rezaie
>>
>> Iran University of Science and Technology
>> Department of Computer Science & Engineering
>> System Software Group
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>
>>     
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> .
>
>   

Re: page table question!

[Mark Williamson]

> I try to read the paging part code of xen-3.1.0, and I am confused about
> the " compat_machine_to_phys_mapping" ,what does xen do with the
> "CONFIG_COMPAT",and what are the differences between the
> "machine_to_phys_mapping" and the "compat_machine_to_phys_mapping"?

Compat-mode guests are 32-bit PAE guests running on a 64-bit hypervisor.  
Certain Xen API data structures need to be translated for compat-mode guests 
to access them; I guess the M2P mapping must be one of them but it's not 
immediately obvious to me what the differences would be.

For things like the start info / shared info page, which will also be 
different for compat-mode guests, it's more obvious since at the least there 
are probably some fields that are 64-bit or 32-bit depending on the guest 
mode...

Cheers,
Mark

> Could you help me
> Thanks in advance
>
> Petersson, Mats 写道:
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com
> >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie
> >> Sent: 13 June 2007 15:55
> >> To: xen-devel@lists.xensource.com
> >> Subject: [Xen-devel] page table question!
> >>
> >> I want to know any difference between writing, reading and shadow page
> >> table (for example performance).
> >
> > Not sure exactly what you're asking for: are you asking about "writable"
> > and "non-writable" page-table vs. shadow-page-table?
> >
> > I believe "writable" page-table means that the guest is able to write
> > DIRECTLY to the lower level(s) of the page-table, and as such, we
> > "trust" the guest to do this correctly (and not map in stuff that
> > doesn't belong to the guest). I believe this mode isn't normally used by
> > Xen guests. This mode relies on the guest to correctly translate the
> > guest-physical address to a machine physical address.
> >
> > Non-writable page-tables are mapped "read-only" throughout the entire
> > page-table, and when a write occurs, the page-table is updated via the
> > emulation of the instruction in the hypervisor. The hypervisor can check
> > that the machine physical address is correct for the particular guest.
> >
> > As of currently, Shadow-mode is only used for HVM (fully virtualized)
> > domains. In this case, the guest has a "dummy" page-table that is not
> > used by the processor for any memory accesses, instead a "shadow" (copy)
> > of the guest's page-table is used. The shadow page-table is used by the
> > processor. To make updates to the page-table appear in the
> > shadow-page-table, the hypervisor is making sure that the
> > guest-page-table is read-only, and when the guest writes to the
> > page-table, we reproduce the write [with modification to reflect the
> > difference between guest physical and machine physical address].
> >
> > --
> > Mats
> >
> >> I am thankful for any help or resource for that.
> >>
> >> --
> >> Best Regards
> >> Mohamad Taghi Mir Mohamad Rezaie
> >>
> >> Iran University of Science and Technology
> >> Department of Computer Science & Engineering
> >> System Software Group
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
> > .
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: page table question!

[MT Rezaie]

Thanks a lot Mark!
I got what I wanted.

best regards
Mohammad