Lines Matching full:hv
13 * hypervisor (HV) and secure memory managed by Ultravisor (UV).
15 * The page-in or page-out requests from UV will come to HV as hcalls and
16 * HV will call back into UV via ultracalls to satisfy these page requests.
22 * on the HV side. Some pages (like virtio buffers, VPA pages etc) are
23 * shared between UV and HV. However such pages aren't represented by
25 * UV and HV page tables.
34 * or when HV and guest simultaneously access the same page.
35 * This mutex serializes the migration of page from HV(normal) to
40 * fault path as page-out can occur when HV faults on accessing secure
44 * by HV touching secure pages is very very low. If an when UV supports
59 * and H_SVM_PAGE_OUT hcalls in PAGE_SIZE(64K) granularity. HV tracks
61 * 64K secure GPA. UV_PAGE_IN and UV_PAGE_OUT calls by HV are also issued
64 * HV faulting on secure pages: When HV touches any secure page, it
72 * HV invalidating a page: When a regular page belonging to secure
73 * guest gets unmapped, HV informs UV with UV_PAGE_INVAL of 64K
78 * Page fault handling: When HV handles page fault of a page belonging
83 * In summary, the current secure pages handling code in HV assumes
500 * Provision a new page on HV side and copy over the contents
552 * - When HV touches a secure page, for which we do UV_PAGE_OUT in __kvmppc_svm_page_out()
594 * is HV side fault on these pages. Next we *get* these pages, forcing
679 * PFN will be used to keep track of the secure page on HV side.
858 * Shares the page with HV, thus making it a normal page.
923 * memory in is visible from both UV and HV.
981 * Fault handler callback that gets called when HV touches any page that
1158 * Don't fail the initialization of kvm-hv module if in kvmppc_uvmem_init()