-
All low-level memory operations go through Xen.
-
Guest OSes are responsible for allocating and initializing PTs for processes (restricted to read only access)
-
allocates and initialize a page and register it with Xen to serve as the new PT
-
-
Direct page writes are intercepted, validated and applied by the Xen VMM
-
update can be batched into a single hypercall (reduce cost of entering/exiting Xen)
-
-
page_info struct associated with each machine page frame
-
page type (none, l1, l2, l3, l4, LDT, GDT, RW)
-
reference count – number of references to the page
-
page frame can be reused only when unpinned and its reference count is zero
-
-
Each domain has a maximum and current memory allocation
-
max allocation is set at domain creation time and cannot be modified
-
-
PT updates
-
hypercall –> mmu_update()
-
writable page tables –> vm_assist()
-
-
Xen exists in the top 64MB (0xFC000000 – 0xFFFFFFFF) section of every guest virtual address space (TLB flush avoided when entering/leaving the hypervisor)
-
not accessible or remappable by guest OSes.
-
-
“fast handler” for system calls - direct access from app into guest OS, without going through Xen
-
muse execute outside Ring 0
-
-
Each guest supports a “ballon” memory management driver - that is used by the VMM to dynamically adjust the guest’s memory usage
-
Page fault handling
-
faulting address is written into an extended stack frame on the guest OS stack (normally the faulting address is read from a privileged processor register (CR2))
-
-
In terms of page protection, Ring1/2 are considered to be part of ‘supervisor mode’. The WP bit in CR0 controls whether read-only restrictions are respected in supervisor mode – if the bit is clear then any mapped page is writable. Xen gets around this by always setting the WP bit and disallowing updates to it. xen/arch/x86/boot/x86_32.S#153
-
Xen provides a domain with a list of machine frames during bootstrapping, and it is the domain’s responsibility to create the pseudo-physical address space from this
No guarantee that a domain will receive a contiguous stretch of physical memory. Most OSes do not have good support for operating in a fragmented physical address space.
-
Machine memory
-
entire amount of memory installed in the machine (physical memory)
-
4kB machine page frames numbered consecutively starting from 0.
-
-
Pseudo-physical memory
-
per-domain abstraction.
-
allows a guest OS to consider its memory allocation to consist of a contiguous range of physical page frames starting at physical frame 0.
-
-
machine-to-physical table
-
globally readable table maintained by Xen
-
records the mapping from machine addresses to pseudo-physical addresses
-
table size is proportional to the amount of RAM installed in the machine
-
-
physical-to-machine table
-
per-domain table which performs the inverse (physical-to-machine) mapping.
-
table size is proportional to the memory allocation of the given domain.
-
(XEN) VIRTUAL MEMORY ARRANGEMENT (for DOM0)
(XEN) Loaded kernel: c0100000→c042e254
(XEN) Init. ramdisk: c042f000→c07fca00
(XEN) Phys-Mach map: c07fd000→c086e894 == 454 MB (as can be verified by: xm list)
(XEN) Start info: c086f000→c0870000
(XEN) Page tables: c0870000→c0874000 == 16 MB
(XEN) Boot stack: c0874000→c0875000
(XEN) TOTAL: c0000000→c0c00000
(XEN) ENTRY ADDRESS: c0100000
x86-32 Xen supports only guests with 2-level page tables. PGD = l2, PTE =l1
How to intercept interrupts from guest domains
http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00597.html
http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00604.html
Page fault handling for Xen guests
http://lists.xensource.com/archives/html/xen-devel/2006-02/msg00263.html
show pagetable walk if guest cannot handle page
http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00612.html
Memory management, mapping, paging questions...
http://lists.xensource.com/archives/html/xen-devel/2006-10/msg01151.html
Information related to shadowing
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00319.html
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00793.html
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00802.html
How to intercept memory operation in Xen
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00659.html
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00664.html
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg00717.html
alert message from dom0 to domU
http://lists.xensource.com/archives/html/xen-devel/2006-12/msg00967.html
Share Memory Between DomainU and Domain0
http://lists.xensource.com/archives/html/xen-devel/2006-12/msg01008.html
Call hypercall straightly from user space
http://lists.xensource.com/archives/html/xen-devel/2006-12/msg01061.html
xen/arch/x86/traps.c#do_page_fault –> fixup_page_fault –> mm.c#ptwr_do_page_fault
xen-3.0.2-2/xen/arch/x86/setup.c#__start_xen()
| \
v \
xen-3.0.2-2/xen/common/domain.c#domain_create() \
| \
v \
xen-3.0.2-2/xen/arch/x86/domain.c#arch_domain_create() \
\
v
xen-3.0.2-2/xen/arch/x86/domain_build.c#construct_dom0()
Xen-ELF image vmlinux-syms-2.6.16-xen has a special'__xen_guest' section
Xen hypercall table:
/xen-3.0.2-2/xen/arch/x86/x86_32/entry.S
#I think this is called when DOM0 attempts to create a DOMU
xen-3.0.2-2/xen/common/dom0_ops.c#do_dom0_op()
trousers-0.2.7/src/tspi/spi_tpm.c#Tspi_TPM_Quote()
|
v
trousers-0.2.7/src/tcsd_api/calltcsapi.c#TCSP_Quote()
|
v
trousers-0.2.7/src/tcsd_api/tcstp.c#TCSP_Quote_TP()
|
v
trousers-0.2.7/src/tcsd_api/tcstp.c#sendTCSDPacket()
原文：https://wiki.cs.dartmouth.edu/nihal/doku.php/xen:memory
|
一.x86_64是怎么嵌入到Dom0的线性空间的
IA32是通过段保护机制做到的：高64M为Ring-0的Xen空间； 1G-64M为Kernel的Ring-1空间； 其他的3G给Application x86_64没有段保护机制，必须用页保护机制：2^64-2^47 --> 2^64 == 内核空间 0 --> 2^47 == 用户空间 中间空的部分可以作为他用 == 被Xen用了 二.Xen采用直接模式 == Guest OS使用自己的页表直接访问HPA 方法: 页表里的内容为HPA；页表项Guest OS只可读；普通的页Guest OS可直接读写。 一旦更新引起Page异常。如果想要更新/操作页表，可以调用相应的Hypercall。 VMM也能保证Guest OS只能访问自己的内存。 Guest OS操作内存的流程： 1.Guest OS访问一个新内存地址(GVA)，PageFault ==> 更新Guest OS的页表 2.Guest OS先找到页表的GPA,VMM根据GPA找到该GPA对应的HPA(通过P2M) ==> 相当于页表更新，调用页表更新的Hypercall(GPA,HPA) 3.如果子页表不存在，需要挂接该子页 ==> 相当于页表挂接操作，调用页表操作的Hypercall(线性地址，HPA) 4.访问该PT表，重复以上2-3步，最终得到一个GVA==>HPA的地址 三.可写页表 由于对页表的操作开销比较大(每次都要进行Hypercall调用)，在某些情况下可以改进它()。 方法是:先把页表(实际上只要把总表PD表)拿下来，不让别人访问，把它作为Guest OS的普通的可读写页 Guest OS随便更改，很多次更改完成后，最后提交给Hypercall，让VMM一次完全的完成更新操作。 前提：PAE模式。因为PDE只有一个PD页。 四.Balloon驱动（存在的Dom0和DomU中） 为Dom0和DomU申请/释放内存 可以查看自己和全Machine的内存状况 Balloon驱动根据设置在XenStore的中的目标值来自动调整它的内存的大小。 五.共享页是怎么实现的 Start Info Page(包括里面的内容)是VMM在Domain初始化时拼成的，它的内容包括了Shared Info Page和XenStore的连接，进入Domain的前几件事就是把本Doamin的Shared Info Page利用页表更新上真正VMM已经分配了的存在Start Info Page。 HVM的PV驱动(主要是)当然也要用Shared Info Page，它的Shared Info Page是自己拼成的。 4.就算是Dom0利用VT-x不也很好吗，用了吗？ 没有用，半虚拟化不需要用VT-x技术，目的是为了提高系统的性能 5.PAE模式是什么，有什么影响 物理地址扩展 (PAE) 允许将最多64GB 的物理内存用作常规的4KB 页面，并扩展内核能使用的位数以将物理内存地址从32扩展到36。 Dom0只有在迁移的时候才用到影子页表，其他时候都用直接访问物理内存。 注释： |