Real-mode support. What's needed ?

Real-mode support. What's needed ?

[James Jacobsson]

I've gotten a fair bit on my device emulation code. The linux kernel
is actually booting all the way to mounting the root FS right now.
Currently I'm working on sorting out some bugs in the ATA irq
handling, so there's definitely some progress.
Thanks for your help, Avi and Dor. I wouldn't gotten this far this
fast without your help.

However, I'm currently "cheating" by loading 32 bit ELF binaries and
executing them, instead of doing a complete boot sequence starting
with a BIOS. This will of course stop me dead in the tracks if I
wanted to launch anything but OSS *NIX systems.

So, my question is:
What's needed to get the x86_emulate.c code in a better state (the
TODO page says something needs to be done), and how would I go about
starting KVM in real-mode?
Will it do everything right if I just set cr0 to indicate that we're
not executing in 32bit more?
Will KVM spit out some kind of debug information when it encounters an
instruction it cannot handle ?

/James

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Real-mode support. What's needed ?

[Avi Kivity]

James Jacobsson wrote:
> I've gotten a fair bit on my device emulation code. The linux kernel
> is actually booting all the way to mounting the root FS right now.
>   

Very impressive.  I keep saying how kvm isn't tied to qemu, but I never 
thought someone would go and actually do it.

> Currently I'm working on sorting out some bugs in the ATA irq
> handling, so there's definitely some progress.
> Thanks for your help, Avi and Dor. I wouldn't gotten this far this
> fast without your help.
>
> However, I'm currently "cheating" by loading 32 bit ELF binaries and
> executing them, instead of doing a complete boot sequence starting
> with a BIOS. This will of course stop me dead in the tracks if I
> wanted to launch anything but OSS *NIX systems.
>
> So, my question is:
> What's needed to get the x86_emulate.c code in a better state (the
> TODO page says something needs to be done), and how would I go about
> starting KVM in real-mode?
> Will it do everything right if I just set cr0 to indicate that we're
> not executing in 32bit more?
>   

The vcpu creation ioctl() creates a vcpu just after a reset - that is, 
ready to run the first bios instruction.

You will need to load your bios to physical address 0xf0000, but that's it.

> Will KVM spit out some kind of debug information when it encounters an
> instruction it cannot handle ?
>
>   

It will say 'emulation failed but !something' and the instruction opcodes.


x86_emulate.c does need an overhaul.  It can boot Windows and some 
Linuces but some boot loaders confuse it.

The following needs to be done:
- get rid of the dependency on cr2.  I did most of this work by adding 
mod r/m decoding, however a bit more needs to be done for absolute 
address references.
- add support for reg/reg instructions.  For example, mov reg, mem is 
supported but mov reg, reg is not.
- add support for more instructions - branches, stack operations, etc.

I see that Xen has been doing much the same for their x86_emulate.c, so 
we can probably pick up some of the changes from them.

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Real-mode support. What's needed ?

[Dor Laor]

>
>I've gotten a fair bit on my device emulation code. The linux kernel
>is actually booting all the way to mounting the root FS right now.
>Currently I'm working on sorting out some bugs in the ATA irq
>handling, so there's definitely some progress.

Cheers for the good work :)
>Thanks for your help, Avi and Dor. I wouldn't gotten this far this
>fast without your help.

It was the least we could do.
>However, I'm currently "cheating" by loading 32 bit ELF binaries and
>executing them, instead of doing a complete boot sequence starting
>with a BIOS. This will of course stop me dead in the tracks if I
>wanted to launch anything but OSS *NIX systems.
>
>So, my question is:
>What's needed to get the x86_emulate.c code in a better state (the
>TODO page says something needs to be done), and how would I go about
>starting KVM in real-mode?

The effort required is to emulate all the necessary instructions to be
able to emulate completely the real mode executions of the popular
guests( Linux/window/Solaris..).  The problem lies in the tough tests
that Intel is doing on vm entry in real mode.
Complete real mode emulation must be implemented inside the KVM - at
least all the common instructions.

It would be superb if you'll take over this. If you do we'll help as
much as possible.

>Will it do everything right if I just set cr0 to indicate that we're
>not executing in 32bit more?

The vmx_vcpu_setup starts in real mode - check the end when calling
vmx_set_cr0 (checking the CR0_PE_MASK bit).

>Will KVM spit out some kind of debug information when it encounters an
>instruction it cannot handle ?

x86_emulate_memop return -1 on error and 0 on success.
It's possible thought that there are bugs hiding too.

Use the force luke !
>
>/James
>
>-----------------------------------------------------------------------
--
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD
EV
>_______________________________________________
>kvm-devel mailing list
>kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/kvm-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV