| 
    
 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Dom0 Virtual Memory
 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 
 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel 
 
 
  | 
  
![]()  | 
            
         Lists.xenproject.org is hosted with RackSpace, monitoring our  |