Thank you for the quick replay.
Sorry, I got a bit confused. It''s obvious that each OS have a virutal
memory
manger to translate virtual addresses to physical addresses. I didn''t
know
what shadow mode means and I saw some CR3 handling / a lot of page-tables
structures.
What are all those l1 l2 l3 page tables in page.h? are they being used only
for shadowed guests?
What I''m trying to achieve is the ability to write to dom0 virtual
memory
from Xen (translate them to machine addresses). Is there an easy method to
do that? (except from using the event channel and do that from dom0 itself).
Are there any genric functions (in page.h) to handle that? I also saw that
dom0 pfns corresponds to the real mfns in order to create a 1:1 match for
DMA to work. Btw, does xen keeps track of the real hardware resources? or is
it just letting the operating system handle this?
Thanks,
Eric.
On 10/23/06, Petersson, Mats <Mats.Petersson@amd.com>
wrote:>
> I''m not sure if this is answering the right or wrong question,
but I
> think you''re missing a bit somewhere.
>
> Xen is managing the MACHINE PHYSICAL memory and the GUEST is believing
> that the GUEST PHYSICAL is "real" physical memory. The next level
above,
> which is the OS''s handling of virtual to physical and physical to
virtual
> will just handle this as if GUEST PHYSICAL really was the true picture of
> the world. There are however some places where the difference is
"real" -
> drivers that use direct memory access (bus mastering) will need to have the
> bus-address, and until IOMMU is a reality for most people, the bus-address
> is MACHINE PHYSICAL. So there''s special code inside the
device-drivers to
> handle the translation of the GUEST PHYSICAL to MACHNE PHYSICAL when
> translating the virtual address given by the user-mode application into a
> PHYSICAL address.
>
> The tables used to manage virtual to guest-physical is the page-tables.
> Obviously, for ease of use, the OS will also implement some sort of virtual
> to physical and physical to virtual tables to translate between the two as
> necessary.
>
> In HVM (or any other case of "shadow mode"), you can use
> shadow_gva_to_[gfn,gpa] to get the guest-physical address, and then
> sh_vcp_gfn_to_mfn() to translate that to a machine frame. mfn_x appears to
> translate that to a "real address" - although my 2 minutes of
grepping
> didn''t find it...
>
> --
> Mats
>
> ------------------------------
> *From:* xen-devel-bounces@lists.xensource.com [mailto:
> xen-devel-bounces@lists.xensource.com] *On Behalf Of *Eric Benton
> *Sent:* 23 October 2006 11:42
> *To:* xen-devel@lists.xensource.com
> *Subject:* [Xen-devel] Dom0 Virtual Memory
>
> Hi,
>
> I looked at the sources and figured out all about the P2M, M2P tables and
> mappings,
> Now I''m trying to figure out how dom0 virtual memory is
implemented, and I
> have some questions.
>
> The platform I''m working on is x86 with Intel VT enabled.
>
> 1. Is dom0 virtual memory managed differently than the other domains? what
> about hvms? and domUs?
> 2. What tables are used to manage the virtual memory?
> 3. What is the easiest method to do a dom0 virtual address to machine
> address translation (from Xen itself)?
>
> Thanks for your help in advance!
>
> Cheers,
> Eric.
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel