Re: Questions about the real mode in kvm/qemu

[Paolo Bonzini <pbonzini@redhat.com>]

On 26/09/19 09:52, Li Qiang wrote:
> Hi Paolo and all,
> 
> There are some question about the emulation for real mode in kvm/qemu.
> For all the 
> question I suppose the 'unstrict guest' is not enabled. 
> 
> 1. how the protected mode CPU emulate the real mode? It seems it uses
> vm86, however, vm86 is not available in x86_64 CPU? So what's the
> 'to_vmx(vcpu)->rmode.vm86_active' here vm86 means?

vm86 mode is available in 64-bit CPUs; it is not available in 64-bit
mode (EFER.LMA=1).

Once KVM places the processor in VMX non-root mode (VMLAUNCH/VMRESUME),
the processor can leave 64-bit mode and run in vm86 mode.  And that's
exactly what KVM does on processors without unrestricted guest support.

In that mode, KVM will start trapping all exceptions and send them to
handle_rmode_exception.  This in turn will either emulate privileged
instructions (for #GP or #SS) or inject them as realmode exceptions.

However...

> 2. Does the guest's real mode code run directly in native CPU? It seems
> 'vmx->emulation_required' is also be false, it the vmx_vcpu_run will do
> a switch to guest.

... as soon as the guest tries to enter protected mode, it will get into
a situation which is not real mode but doesn't have the segment
registers properly loaded with selectors.  Therefore, it will either
hack things together (enter_pmode) or emulate instructions until the
state is accepted even without unrestricted guest support.

The "hacking things together" part however does not work for big real
mode (where you enter 32-bit mode, load segment registers with a flat 4G
segment, and go back to real mode with the 4G segments).  In big real
mode, therefore, KVM cannot use vm86 and will keep emulating (slowly -
up to 1000x slower than unrestricted guest).

> 3. How the EPT work in guest real mode? The EPT is for GVA->GPA->HPA,
> however there is no GVA, seems the identity mapping does something. But
> there also some confusion for me. For example the real mode uses CS*4 +
> IP to address the code.  Who does this calculation? In the kernel emulator? 

Right, and in fact the CR0.PG and CR0.PE bits must be 1 when running in
VMX non-root mode with unrestricted guest disabled.

Therefore, KVM places a 4 KiB identity map at an address provided by
userspace (with KVM_SET_IDENTITY_MAP_ADDR).  When 1) EPT is enabled 2)
unrestricted guest isn't 3) CR0.PG=0, KVM points CR3 to it and runs the
guest with CR0.PG=1, CR4.PAE=0, CR4.PSE=1.  This CR4 setup enables 4 MiB
huge pages so that a 4 GiB identity map fits in 4 KiB.  This is the only
case where EPT is enabled but CR3 loads and stores will trap to the
hypervisor.  This way, the guest CR3 value is faked in the vmexit
handler, but the processor always uses the identity GVA->GPA mapping.

Paolo