Re: Questions about the real mode in kvm/qemu

[Maxim Levitsky <mlevitsk@redhat.com>]

On Thu, 2019-09-26 at 11:15 +0200, Paolo Bonzini wrote:
> 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.
Ah, so you run vm86 inside the guest, to emulate the real mode.
That is clever :-)

> 
> 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).
That is also understandable.

> 
> > 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.

Ah, so you fake the guest's paging table, not the EPT table. That makes
sense.

Thankfully all of this is not needed when unrestricted guest is available.

Best regards,
	Maxim Levitsky