memory pinning, mapping update, writable mapping에 대한 mailing

## xen memory에 대한 몇가지 이야기 ##
- 김환주

- The meaning of ‘pin and unpin’ in Xen

Pinning이란 guest가 페이지가 가져야 하는 유형이 무엇인지 Xen에게 알려주는 메커니즘이다. 이것은 성능 최적화와 관련이 있다.(?) 예를 들어, guest가 “이 페이지는 페이지 테이블 엔트리를 가지고 있는 페이지이다.” 라고 pinning을 한다면 Xen은 실제로 이 페이지가 vailid한 엔트리를 포함하고 있는지 검사하고, 그 페이지를 guest가 임의로 수정할 수 없도록 write protect를 시킨다. 이 페이지는 unpin 될 때 까지 pin되었을 때의 페이지 유형과 유효 상태를 유지한다. Xen은 새로운 페이지 테이블이 로딩 될 때마다 전체 페이지 테이블들에 대해 다시 validation을 할 것이다.

When the refcnt of an L2 table is raised from zero, the whole page
table structure is scanned to check it for safety. If the L2 table did
not explicitly have its refcnt pinned to non-zero then this scanning
would occur every time the table was installed into the hardware MMU.

Pinning is *only* a performance enhancement -- you can get away
without using the mechanism, but it will cost you performance.

-- Keir

Update_va_mapping에 관하여
> hi,
>
> I am trying to guess the purpose of the calls to
> HYPERVISOR_update_va_mapping in mm/memory.c, or rather why this code
> (which apparently handles user space demand paging) uses a special
> hypercall rather than the usual pte-update calls.
>
> Could anyone briefly explain to me what this hypercall does, and why it
> needs to be special?
>
> thanks,
> Jacob

It's faster to execute than doing the same thing via the usual update
hypercall, because:
1. The code executes one special case so it is shorter and
straight-line.
2. Xen modifies the specified PTE directly using the guest-provided
mapping of that PTE. This is faster than creating a temporary mapping
of that page in Xen's address space.

Short answer: it's just a performance optimisation.

-- Keir
Writable page table
A method and system for using writeable page tables to increase performance of memory address translation in computing environments utilizing a hypervisor. Guest operating systems are given temporary write-access to a page table page after the system confirms that such page is not part of the current address space (i.e., confirming that the page is part of a different page table from the one that is currently in use, such as a different user-space process). Alternatively, if the page is part of the currently running page table, the system invalidates the appropriate entry in the root page directory, thus "unlinking" it, and ensuring that the appropriate region of virtual address space is flushed from the translation lookaside buffer (TLB) in the current CPU and others that may be using it. After giving the OS write-access, the page is added to a validation queue. Validation of all 1024 entries and "re-hooking" of the page occurs whenever a page fault is taken due to the page being unhooked, or before context switching to another page table.