WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] How works MMU?

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] How works MMU?
From: Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxxxx>
Date: Mon, 24 Nov 2003 11:06:00 -0500
Delivery-date: Mon, 24 Nov 2003 16:11:39 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) 3.1
I'd like to know if my vision of how MMU works (for the moment a part of it) is
the good one. 

As far as I read, I understand the following things:
1) the hypervisor reserved a 64M virtual area in the top of the virtual memory
2) Inside this area, there is 24M for frame table 

It's my understanding of this frame table which is not clear

I think that the frame table contains a list for each domains. Those lists keep
the mapping between physical adress and guest os kernel space. So, when a guest
OS requests a physical page, it manages its pages directly with the hardware.
The difference with a "normal linux kernel" is that it must ask a page with
read-only access and register the new set of pages to the hypervisor. Then, the
hypervisor add the pages to the list corresping to the domain in the
frame_table. Is it working like this (I don't think so...)? I saw in the source
files that frame_table is updated during do_mmu_update. I think that for guest
os kernel page, the update is done in case MMU_MACHPHYS_UPDATE, but I'm not so
sure...

Otherwise, is the physical mapping for xen virtual memory done between
READONLY_MPT_VIRT_START and READONLY_MPT_VIRT_END?

Would it be possible to explain shortly the principle of the monitor? I saw that
there is a callback mechanism so monitor can respond to domain dependently of an
action. It also has its own virtual area which is reserved but I didn't see the
goal of monitor (is it a part of the domain0 control interface?)

Last question (today ;), you choose to implement a two levels pages MMU. Does it
mean that if an architecture use only a three levels pages MMU you need to
rewrite the common part to allow 3 levels or is there some tricks to only add an
architecture dependant file?
  
Thank you
Guillaume


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] How works MMU?, Guillaume Thouvenin <=