[ToDo] Real Mode Support

[ToDo] Real Mode Support

[Guillaume Thouvenin]

Hello,

  I read on the kvmwiki/TODO that there is a work in progress for
extending x86 emulator to support more instructions in real mode and for
changing the execution loop to call the emulator for real mode. 

  As I'm interested to work on this part I'd like to know what was
already done.

  I'd like to have more information about how the execution loop need to
be changed. Currently we enter/leave real mode through a call to 
enter_rmode()/enter_pmode(). The function sets a variable
"arch.rmode.active" and also sets the bit X86_EFLAGS_VM of
GUEST_RFLAGS. That means that we are using the VM mode to virtualize
the real mode. I know that in virtual mode some instructions can not be
used as they are in full real mode (that would have been too easy). So
these instructions generate a protection fault and need to be emulated.
So we handle this kind of exception in handle_exception() and we call
the x86 emulator. From the emulator we read the eflags
(kvm_x86_ops->get_rflags(vcpu)) and we can know if we are in real mode
or not. It's the current scheme, right?

  My question is why the execution loop needs to be changed here. I mean
isn't it possible to just extend x86 emulator to support more
instructions in real mode? I think that I'm missing something here so
any help, hint, advice, link are welcome. 

Best Regards,

-- 
Guillaume Thouvenin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Izik Eidus]

On Wed, 2008-02-06 at 08:33 +0100, Guillaume Thouvenin wrote:
> Hello,
> 
>   I read on the kvmwiki/TODO that there is a work in progress for
> extending x86 emulator to support more instructions in real mode and for
> changing the execution loop to call the emulator for real mode. 
> 
>   As I'm interested to work on this part I'd like to know what was
> already done.

cool!

> 
>   I'd like to have more information about how the execution loop need to
> be changed. Currently we enter/leave real mode through a call to 
> enter_rmode()/enter_pmode(). The function sets a variable
> "arch.rmode.active" and also sets the bit X86_EFLAGS_VM of
> GUEST_RFLAGS. That means that we are using the VM mode to virtualize
> the real mode. I know that in virtual mode some instructions can not be
> used as they are in full real mode (that would have been too easy). So
> these instructions generate a protection fault and need to be emulated.
> So we handle this kind of exception in handle_exception() and we call
> the x86 emulator. From the emulator we read the eflags
> (kvm_x86_ops->get_rflags(vcpu)) and we can know if we are in real mode
> or not. It's the current scheme, right?
> 
>   My question is why the execution loop needs to be changed here. I mean
> isn't it possible to just extend x86 emulator to support more
> instructions in real mode? I think that I'm missing something here so
> any help, hint, advice, link are welcome. 
> 
> Best Regards,
> 


i am not expert for the emulator area, but as far as i remember:

virtual 8086 have some checks related to segments (the big mode
problem), it mean that for some addresses it wont be able to execute
anything, you will just get vmexit right away, therefor you need a full
functional emulator that will handle everything there.





-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Guillaume Thouvenin]

On Wed, 06 Feb 2008 10:52:54 +0200
Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> 
> i am not expert for the emulator area, but as far as i remember:
> 
> virtual 8086 have some checks related to segments (the big mode
> problem), it mean that for some addresses it wont be able to execute
> anything, you will just get vmexit right away, therefor you need a full
> functional emulator that will handle everything there.

Oh thanks,  I remember now. The problem seems to be with the descriptor
cache register. In protected mode and also in virtual mode the
descriptor cache register is fully loaded each time a segment register
is loaded. It's not the case in real mode. So every program that uses
this "feature" (the big real mode) will not work under vm8086.
Thus we need to remove the usage of the virtual mode and instead we
need to fully emulate the real mode in order to be "big real mode"
compliant.

Does somebody know if there are already some patches or some other stuff
about big real mode support?
 
Regards,
Guillaume

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Izik Eidus]

On Wed, 2008-02-06 at 13:07 +0100, Guillaume Thouvenin wrote:
> On Wed, 06 Feb 2008 10:52:54 +0200
> Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> > 
> > i am not expert for the emulator area, but as far as i remember:
> > 
> > virtual 8086 have some checks related to segments (the big mode
> > problem), it mean that for some addresses it wont be able to execute
> > anything, you will just get vmexit right away, therefor you need a full
> > functional emulator that will handle everything there.
> 
> Oh thanks,  I remember now. The problem seems to be with the descriptor
> cache register. In protected mode and also in virtual mode the
> descriptor cache register is fully loaded each time a segment register
> is loaded. It's not the case in real mode. So every program that uses
> this "feature" (the big real mode) will not work under vm8086.
> Thus we need to remove the usage of the virtual mode and instead we
> need to fully emulate the real mode in order to be "big real mode"
> compliant.
> 
> Does somebody know if there are already some patches or some other stuff
> about big real mode support?

i think that there used to be talks about this before long time ago,
i dont know what the state is (i hard to belive anyone is working on it
right now), but to be sure we will have to wait to avi.

>  
> Regards,
> Guillaume


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Kamble, Nitin A]

I am still holding to few patches for big real mode. After rebase I will
push those patches.

Thanks & Regards,
Nitin
Linux Open Source Technology Center, Intel Corporation
------------------------------------------------------------------------
----
The Mind is like a parachute; it works much better when it's open.

>-----Original Message-----
>From: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:kvm-devel-
>bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Guillaume Thouvenin
>Sent: Wednesday, February 06, 2008 4:07 AM
>To: Izik Eidus
>Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [kvm-devel] [ToDo] Real Mode Support
>
>On Wed, 06 Feb 2008 10:52:54 +0200
>Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>
>> i am not expert for the emulator area, but as far as i remember:
>>
>> virtual 8086 have some checks related to segments (the big mode
>> problem), it mean that for some addresses it wont be able to execute
>> anything, you will just get vmexit right away, therefor you need a
full
>> functional emulator that will handle everything there.
>
>Oh thanks,  I remember now. The problem seems to be with the descriptor
>cache register. In protected mode and also in virtual mode the
>descriptor cache register is fully loaded each time a segment register
>is loaded. It's not the case in real mode. So every program that uses
>this "feature" (the big real mode) will not work under vm8086.
>Thus we need to remove the usage of the virtual mode and instead we
>need to fully emulate the real mode in order to be "big real mode"
>compliant.
>
>Does somebody know if there are already some patches or some other
stuff
>about big real mode support?
>
>Regards,
>Guillaume
>
>-----------------------------------------------------------------------
--
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>kvm-devel mailing list
>kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/kvm-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Alexey Eremenko]

[-- Attachment #1.1: Type: text/plain, Size: 138 bytes --]


Actually having good Real Mode support will really help KVM running wider variety of guest OSes.

Very welcome move.

-Technologov

[-- Attachment #1.2: Type: text/html, Size: 539 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [ToDo] Real Mode Support

[Anthony Liguori]

Guillaume Thouvenin wrote:
> Hello,
>
>   I read on the kvmwiki/TODO that there is a work in progress for
> extending x86 emulator to support more instructions in real mode and for
> changing the execution loop to call the emulator for real mode. 
>   

Yes, Nitin has done some work in this area.

>   As I'm interested to work on this part I'd like to know what was
> already done.
>
>   I'd like to have more information about how the execution loop need to
> be changed. Currently we enter/leave real mode through a call to 
> enter_rmode()/enter_pmode(). The function sets a variable
> "arch.rmode.active" and also sets the bit X86_EFLAGS_VM of
> GUEST_RFLAGS. That means that we are using the VM mode to virtualize
> the real mode. I know that in virtual mode some instructions can not be
> used as they are in full real mode (that would have been too easy). So
> these instructions generate a protection fault and need to be emulated.
> So we handle this kind of exception in handle_exception() and we call
> the x86 emulator. From the emulator we read the eflags
> (kvm_x86_ops->get_rflags(vcpu)) and we can know if we are in real mode
> or not. It's the current scheme, right?
>   

Sort of.  Right now we put the guest into vm86 mode and use that to 
execute real mode code.  There are a number of problems with using vm86 
(some due to VT restrictions on vm86).  The biggest problem is Big Real 
Mode.

In real mode, the x86 uses segmentation only.  Normally, the segment 
limits are setup to be 0xffff and since the translation for segment mode 
is 16-bit segment register * 16, you can address 2^20 work of address space.

However, if you switch to protected mode, you can setup the GDT to have 
4G segments.  If you then switch back to real mode, you can use 32-bit 
address overrides to access the full 32-bit address space in 16-bit mode.

vm86 does not support this trick though.  To further complicate matters, 
there are certain gotcha's when using vm86 with VT that are less easy to 
detect.

So what we would like to do, is instead of setting up vm86 mode for the 
guest to execute real mode, use x86_emulate() to just emulate the code.  
This means that we wouldn't be using the "vmlaunch" instruction when in 
real mode and instead would be doing an x86_emulate() loop.

Regards,

Anthony Liguori

>   My question is why the execution loop needs to be changed here. I mean
> isn't it possible to just extend x86 emulator to support more
> instructions in real mode? I think that I'm missing something here so
> any help, hint, advice, link are welcome. 
>
> Best Regards,
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Izik Eidus]

On Wed, 2008-02-06 at 11:32 -0600, Anthony Liguori wrote:
> Guillaume Thouvenin wrote:
> > Hello,
> >
> >   I read on the kvmwiki/TODO that there is a work in progress for
> > extending x86 emulator to support more instructions in real mode and for
> > changing the execution loop to call the emulator for real mode. 
> >   
> 
> Yes, Nitin has done some work in this area.
> 
> >   As I'm interested to work on this part I'd like to know what was
> > already done.
> >
> >   I'd like to have more information about how the execution loop need to
> > be changed. Currently we enter/leave real mode through a call to 
> > enter_rmode()/enter_pmode(). The function sets a variable
> > "arch.rmode.active" and also sets the bit X86_EFLAGS_VM of
> > GUEST_RFLAGS. That means that we are using the VM mode to virtualize
> > the real mode. I know that in virtual mode some instructions can not be
> > used as they are in full real mode (that would have been too easy). So
> > these instructions generate a protection fault and need to be emulated.
> > So we handle this kind of exception in handle_exception() and we call
> > the x86 emulator. From the emulator we read the eflags
> > (kvm_x86_ops->get_rflags(vcpu)) and we can know if we are in real mode
> > or not. It's the current scheme, right?
> >   
> 
> Sort of.  Right now we put the guest into vm86 mode and use that to 
> execute real mode code.  There are a number of problems with using vm86 
> (some due to VT restrictions on vm86).  The biggest problem is Big Real 
> Mode.
> 
> In real mode, the x86 uses segmentation only.  Normally, the segment 
> limits are setup to be 0xffff and since the translation for segment mode 
> is 16-bit segment register * 16, you can address 2^20 work of address space.
> 
> However, if you switch to protected mode, you can setup the GDT to have 
> 4G segments.  If you then switch back to real mode, you can use 32-bit 
> address overrides to access the full 32-bit address space in 16-bit mode.
> 
> vm86 does not support this trick though.  To further complicate matters, 
> there are certain gotcha's when using vm86 with VT that are less easy to 
> detect.
> 
> So what we would like to do, is instead of setting up vm86 mode for the 
> guest to execute real mode, use x86_emulate() to just emulate the code.  
> This means that we wouldn't be using the "vmlaunch" instruction when in 
> real mode and instead would be doing an x86_emulate() loop.


and for the matter of fact there are not too many instructions that
needed to be emulated in oreder to make it work as that the vm86
instructions are very limited anyway
(15.1.3 in the intel manual list them)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Avi Kivity]

Anthony Liguori wrote:
> So what we would like to do, is instead of setting up vm86 mode for the 
> guest to execute real mode, use x86_emulate() to just emulate the code.  
> This means that we wouldn't be using the "vmlaunch" instruction when in 
> real mode and instead would be doing an x86_emulate() loop.
>   

As using the emulator is likely to be slower than VT, we can call the 
emulator only if we are in a "VT unfriendly" state, so the code might 
look like

    if (vmx->rmode.active && big_real_mode(vmx))
          ...

In addition, there are some protected-mode states that VT can't handle 
(cs.rpl != ss.rpl IIRC) so we can emulate those cases as well.

To improve speed, we may want to emulate >1 instruction per iteration.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Guillaume Thouvenin]

On Sun, 10 Feb 2008 13:44:05 +0200
Avi Kivity <avi@qumranet.com> wrote:

> Anthony Liguori wrote:
> > So what we would like to do, is instead of setting up vm86 mode for the 
> > guest to execute real mode, use x86_emulate() to just emulate the code.  
> > This means that we wouldn't be using the "vmlaunch" instruction when in 
> > real mode and instead would be doing an x86_emulate() loop.
> >   
> 
> As using the emulator is likely to be slower than VT, we can call the 
> emulator only if we are in a "VT unfriendly" state, so the code might 
> look like
> 
>     if (vmx->rmode.active && big_real_mode(vmx))
>           ...
> 
> In addition, there are some protected-mode states that VT can't handle 
> (cs.rpl != ss.rpl IIRC) so we can emulate those cases as well.
> 
> To improve speed, we may want to emulate >1 instruction per iteration.

So the plan is to keep the usage of vm86 mode until we detect a "VT
unfriendly" state. I think about a VMentry failure to detect this kind
of state?

Then, when we are in big_real_mode state, we emulate the code as
suggested by Avi with the optimisation that consists to emulate more
than one instruction per iteration.

Best regards,
Guillaume

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [ToDo] Real Mode Support

[Avi Kivity]

Guillaume Thouvenin wrote:
>>>   
>>>       
>> As using the emulator is likely to be slower than VT, we can call the 
>> emulator only if we are in a "VT unfriendly" state, so the code might 
>> look like
>>
>>     if (vmx->rmode.active && big_real_mode(vmx))
>>           ...
>>
>> In addition, there are some protected-mode states that VT can't handle 
>> (cs.rpl != ss.rpl IIRC) so we can emulate those cases as well.
>>
>> To improve speed, we may want to emulate >1 instruction per iteration.
>>     
>
> So the plan is to keep the usage of vm86 mode until we detect a "VT
> unfriendly" state. I think about a VMentry failure to detect this kind
> of state?
>   

Yes, that's a good way.

> Then, when we are in big_real_mode state, we emulate the code as
> suggested by Avi with the optimisation that consists to emulate more
> than one instruction per iteration.
>
>   

Yes.  Note we sometimes need to emulate in protected mode as well.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/