- 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 64 MB (0xfc000000-0 xffffffff) 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 cballs-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 OSStack (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 authentication action.
- Allows a guest OSTo 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 'sectionxen 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 DOMUxen-3.0.2-2/xen/common/dom0_ops.c # do_dom0_op () trousers-0.2.7/src/tspi/spi_tpm.c # consume () | vtrousers-0.2.7/src/tcsd_api/calltcsapi. C # tcsp_quote () | vtrousers-0.2.7/src/tcsd_api/tcstp. C # tcsp_quote_tp () | vtrousers-0.2.7/src/tcsd_api/tcstp. C # sendtcsdpacket ()
Original article: https://wiki.cs.dartmouth.edu/nihal/doku.php/xen:memory
I. How is x86_64 embedded in the linear space of dom0?
Ia32 is implemented through the block protection mechanism: the 64 m high is the xen space of ring-0;
1g-64m is the ring-1 space of the kernel;
Other 3G applicationsX86_64 has no segment protection mechanism and must use the page protection mechanism: 2 ^ 64-2 ^ 47 --> 2 ^ 64 = kernel space
0 --> 2 ^ 47 = user space
The blank part in the middle can be used as he used = and used by xen. Ii. xen adopts direct mode = Guest OS uses its own page table to directly access HPA
Method: The content in the page table is HPA, the page table item Guest OS is readable only, and the common page Guest OS can be read and written directly.
Page exception occurs once an update occurs. To update/operate the page table, you can call the corresponding hypercall.
Vmm also ensures that the guest OS can only access its own memory.
Guest OS Memory Operation Process:
1. Access a new memory address (GVA) from guest OS, pagefault ==> update the page table of guest OS
2. Guest OS first finds the page table's GPA, and vmm finds the HPA corresponding to this GPA Based on the GPA (through p2m)
==> This is equivalent to page table update. hypercall (GPa, HPA) for page table update is called)
3. If the sub-page table does not exist, you need to mount the sub-page
==> This is equivalent to the page table mounting operation. It calls the hypercall (linear address, HPA) of the page table operation)
4. Access the PT table and repeat the preceding two-3 steps to obtain a GVA ==> HPA address. 3. writeable page tables
Because the operation overhead on the page table is relatively large (hypercall is required every time), it can be improved in some cases ().
The method is: first take the page table (in fact, as long as the total table PD table) down, do not allow others to access it, use it as a normal readable/writable page of the guest OS
The Guest OS can be changed at will. After many changes are completed, it is finally submitted to hypercall to allow the vmm to complete the update operation completely at a time.
Prerequisite: PAE mode. This is because there is only one PD page. 4. Balloon Driver (in dom0 and domu)
Apply for/release memory for dom0 and domu
You can view the memory status of yourself and the whole machine.
The balloon driver automatically adjusts its memory size based on the target value set in xenstore. 5. How to Implement shared pages
Start info page (including the content) is formed by vmm during domain initialization. Its content includes the connection between shared info page and xenstore, the first few things before entering the domain are to update the shared info page of this doamin using the page table to the existing start info page that has been allocated by the real vmm.
Of course, the PV Driver (mainly) of hvm should also use shared info page. Its shared info page is self-assembled. 4. Isn't it good for dom0 to use VT-X?
No. The VT-x technology is not required for semi-virtualization, so as to improve the system performance.
5. What is the PAE mode and its impact?
The physical address extension (PAE) allows a maximum of 64 GB of physical memory to be used as a regular 4 kb page, and expands the number of places used by the inner nuclear energy to expand the physical memory address from 32 to 36. Dom0 uses the shadow page table only during migration, and directly accesses the physical memory at other times. Note:
GPFN/GFN: guset page frame number the customer's physical page number (the customer's operating system uses GPFN/GFN to address the customer's physical address space)
MFN: Machine page frame number machine page number
Smfn: Machine page frame number for shadow pages the machine page number where the shadow page is located
L1e: Level 1 page table entry
Gl1e: Level 1 guest page table entry
Sl1e: Level 1 shadow page table entry level 1 shadow page table item
PV: para-virtualization alization
Hvm: hardware assistant Virtual Machine |
