| 1017 | #define vmx_setup_cr4_shadow(vmcs,init) vmx_setup_cr_shadow(4, (vmcs), (init)) |
| 1018 | |
| 1019 | static void * |
| 1020 | vmx_init(struct vm *vm, pmap_t pmap) |
| 1021 | { |
| 1022 | uint16_t vpid[VM_MAXCPU]; |
| 1023 | int i, error; |
| 1024 | struct vmx *vmx; |
| 1025 | struct vmcs *vmcs; |
| 1026 | uint32_t exc_bitmap; |
| 1027 | uint16_t maxcpus; |
| 1028 | |
| 1029 | vmx = malloc(sizeof(struct vmx), M_VMX, M_WAITOK | M_ZERO); |
| 1030 | if ((uintptr_t)vmx & PAGE_MASK) { |
| 1031 | panic("malloc of struct vmx not aligned on %d byte boundary", |
| 1032 | PAGE_SIZE); |
| 1033 | } |
| 1034 | vmx->vm = vm; |
| 1035 | |
| 1036 | vmx->eptp = eptp(vtophys((vm_offset_t)pmap->pm_pmltop)); |
| 1037 | |
| 1038 | /* |
| 1039 | * Clean up EPTP-tagged guest physical and combined mappings |
| 1040 | * |
| 1041 | * VMX transitions are not required to invalidate any guest physical |
| 1042 | * mappings. So, it may be possible for stale guest physical mappings |
| 1043 | * to be present in the processor TLBs. |
| 1044 | * |
| 1045 | * Combined mappings for this EP4TA are also invalidated for all VPIDs. |
| 1046 | */ |
| 1047 | ept_invalidate_mappings(vmx->eptp); |
| 1048 | |
| 1049 | msr_bitmap_initialize(vmx->msr_bitmap); |
| 1050 | |
| 1051 | /* |
| 1052 | * It is safe to allow direct access to MSR_GSBASE and MSR_FSBASE. |
| 1053 | * The guest FSBASE and GSBASE are saved and restored during |
| 1054 | * vm-exit and vm-entry respectively. The host FSBASE and GSBASE are |
| 1055 | * always restored from the vmcs host state area on vm-exit. |
| 1056 | * |
| 1057 | * The SYSENTER_CS/ESP/EIP MSRs are identical to FS/GSBASE in |
| 1058 | * how they are saved/restored so can be directly accessed by the |
| 1059 | * guest. |
| 1060 | * |
| 1061 | * MSR_EFER is saved and restored in the guest VMCS area on a |
| 1062 | * VM exit and entry respectively. It is also restored from the |
| 1063 | * host VMCS area on a VM exit. |
| 1064 | * |
| 1065 | * The TSC MSR is exposed read-only. Writes are disallowed as |
| 1066 | * that will impact the host TSC. If the guest does a write |
| 1067 | * the "use TSC offsetting" execution control is enabled and the |
| 1068 | * difference between the host TSC and the guest TSC is written |
| 1069 | * into the TSC offset in the VMCS. |
| 1070 | * |
| 1071 | * Guest TSC_AUX support is enabled if any of guest RDPID and/or |
| 1072 | * guest RDTSCP support are enabled (since, as per Table 2-2 in SDM |
| 1073 | * volume 4, TSC_AUX is supported if any of RDPID and/or RDTSCP are |
| 1074 | * supported). If guest TSC_AUX support is enabled, TSC_AUX is |
| 1075 | * exposed read-only so that the VMM can do one fewer MSR read per |
| 1076 | * exit than if this register were exposed read-write; the guest |
nothing calls this directly
no test coverage detected