Question about EMULATE_DO_MMIO

Question about EMULATE_DO_MMIO

[Nitin A Kamble]

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

Hi Avi,
   I was trying to avoid vm86 mode completely, by using emulation for
all the real mode code emulation. It is doing better than vm86 mode, but
I am seeing one issue with this approch.

   The emulator is failing due to this code. Seems like the execution
need to go back to qemu to finish some pending MMIO.

       if (vcpu->mmio_is_write) {
                vcpu->mmio_needed = 0;
                return EMULATE_DO_MMIO;
        }

Do you have how should it be handled? I am not clear what needs to be
done to handle this situation properly.

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- 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: Question about EMULATE_DO_MMIO

[Avi Kivity]

Nitin A Kamble wrote:
> Hi Avi,
>    I was trying to avoid vm86 mode completely, by using emulation for
> all the real mode code emulation. It is doing better than vm86 mode, 

Why do you think it is better?  I would have thought that vm86 is much
faster.

I thought of doing it this way:

- try to run normally
- if vm entry failed due to invalid guest state (the famous 0x80000021),
then emulate 50 instructions
- repeat

That will also handle the few cases where VT can't handle protected mode.

> but
> I am seeing one issue with this approch.
>
>    The emulator is failing due to this code. Seems like the execution
> need to go back to qemu to finish some pending MMIO.
>
>        if (vcpu->mmio_is_write) {
>                 vcpu->mmio_needed = 0;
>                 return EMULATE_DO_MMIO;
>         }
>
> Do you have how should it be handled? I am not clear what needs to be
> done to handle this situation properly.
>   

It should exit to userspace, same as the non-emulating case.  However it
shouldn't happen for normal writes.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: Question about EMULATE_DO_MMIO

[Nitin A Kamble]

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

On Tue, 2007-10-16 at 13:12 -0700, Avi Kivity wrote:

> Why do you think it is better?  I would have thought that vm86 is much
> faster.
> 
I am seeing execution going to strange places in vm86 mode. That issue
is not coming in the emulation.

> I thought of doing it this way:
> 
> - try to run normally
> - if vm entry failed due to invalid guest state (the famous
> 0x80000021),
> then emulate 50 instructions
> - repeat
This may be better, I will give it a try.

> That will also handle the few cases where VT can't handle protected
> mode.
> 
> It should exit to userspace, same as the non-emulating case.  However
> it
> shouldn't happen for normal writes.
> 
Only thing is if it in the real mode, then returning back to user mode
will setup the cpu state as real mode, and because of that vmenter will
fail.

> 
> --
> Do not meddle in the internals of kernels, for they are subtle and
> quick to panic.
> 
> 

Thanks a lot for your input.

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- 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: Question about EMULATE_DO_MMIO

[Avi Kivity]

Nitin A Kamble wrote:
> On Tue, 2007-10-16 at 13:12 -0700, Avi Kivity wrote:
>
>   
>> Why do you think it is better?  I would have thought that vm86 is much
>> faster.
>>
>>     
> I am seeing execution going to strange places in vm86 mode. That issue
> is not coming in the emulation.
>
>   

That means there's a bug somewhere.  We need to fix it.


>> That will also handle the few cases where VT can't handle protected
>> mode.
>>
>> It should exit to userspace, same as the non-emulating case.  However
>> it
>> shouldn't happen for normal writes.
>>
>>     
> Only thing is if it in the real mode, then returning back to user mode
> will setup the cpu state as real mode, and because of that vmenter will
> fail.
>   

It will fail, and we'll see it and go back to emulation.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/