Guest CR3 logical processor in virtualized enviroment

[cianfa72]

Another point related to my previous question.

Intel VMCS structure has separate logical areas for Guest and Host. Guest logical area stores the CR3 register for the guest, while the host area the CR3 register used from host'VMM.

When a logical processor with EPT enabled runs in VMX non-root mode for a VM, the VMCS guest CR3 register value stores the guest physical address of the first level of the guest page table hierarchy (e.g. PMLT4 4KiB table in case of 4-level page tables for the guest).

Now my question is: as far as I can tell with EPT disabled the logical processor's CR3 hardware register stores a machine physical memory address (MPA) even when it runs in VMX non-root mode in the context of a VM's vCPUs.

Now the question: suppose guest code wants read vCPU's CR3 register, e.g.

Code: Select all

mov eax, cr3

How can it actually get the correct Guest Physical Address (GPA) value ?

[Octocontrabass]

If EPT is disabled, the VMM traps and emulates the instruction so the guest will see the expected guest physical address.

If EPT is enabled, the VMM doesn't need to do anything special because CR3 already contains a guest physical address.

[cianfa72]

If EPT is disabled, the VMM traps and emulates the instruction so the guest will see the expected guest physical address.

You mean that upon guest OS code tries to execute in VMX non-root mode the instruction:

Code: Select all

mov eax, cr3

the logical processor (i.e. physical core or thread/HT) traps into the VMM as a result of a VM-exit. Then it emulates the trapped instruction when in VMX root mode.

How does the VMM handle such VM-exit in this specific case ? As far as I know, VMM code can only access the vCPU's associated VMCS. Therefore in this case I believe it just updates the CR3 field within the relevant VMCS's guest state logical group filling it with the relevant GPA address.

If EPT is enabled, the VMM doesn't need to do anything special because CR3 already contains a guest physical address.

Ok yes, it makes sense.

[Octocontrabass]

How does the VMM handle such VM-exit in this specific case ?

It updates EIP (in VMCS) and EAX, then performs a VM-entry.

As far as I know, VMM code can only access the vCPU's associated VMCS.

VMM code can also access GPRs, since GPRs are not modified by VM-entry or VM-exit.

[cianfa72]

It updates EIP (in VMCS) and EAX, then performs a VM-entry.

Ok, so VMM actually updates the EIP field within VMCS's guest area and the logical processor's EAX register, the latter with the appropriate GPA address (i.e. the guest physical address of the 1st level guest page table hierarchy). After VM-entry, the logical processor in VMX non-root mode loads hardware registers from corresponding fields stored within VMCS's guest area. EAX doesn't exists there, so it is up to VMM to update it with the relevant value before VM-entry.

VMM code can also access GPRs, since GPRs are not modified by VM-entry or VM-exit.

Ok, therefore VMM code can access and update also EAX register since it is a GPR.

Regarding how CR3 register is actually managed I think the following due to A. Einstein applies: "is the moon there when no one looks at? "