Paolo Bonzini <pbonzini@redhat.com> 于2019年9月26日周四 下午5:15写道：

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

So without unrestrict guest the mainline is this:
KVM set guest's rflag bit X86_EFLAGS_VM, so when the guest enter guest
mode, it is in vm86 mode.
In this mode, the CPU will access the address like in real
mode(seg*4+offset), this address is linear address. And in fact, the vm86
is still
in protected, so the linear address will be translated to gpa by the
identity mapping table. Then goes to EPT table?

Is this understanding right?



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

Could you please explain this situation more detailed? Why this happen?

Thanks,
Li Qiang



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