Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-26 Thread Avi Kivity
Anthony Liguori wrote:
 The second stage is to use a loop of x86_emulate() to run all 16-bit 
 code (instead of using vm86 mode).  This will allow us to support guests 
 that use big real mode.

   

Why do that unconditionally, instead of only when in a big-real-mode state?

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


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-26 Thread Mohammed Gamal
On Sat, Apr 26, 2008 at 9:49 AM, Avi Kivity [EMAIL PROTECTED] wrote:
 Anthony Liguori wrote:

  The second stage is to use a loop of x86_emulate() to run all 16-bit code
 (instead of using vm86 mode).  This will allow us to support guests that use
 big real mode.
 
 
 

  Why do that unconditionally, instead of only when in a big-real-mode state?

Is big-real-mode the only state where we have problems?

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-26 Thread Anthony Liguori
Avi Kivity wrote:
 Anthony Liguori wrote:
 The second stage is to use a loop of x86_emulate() to run all 16-bit 
 code (instead of using vm86 mode).  This will allow us to support 
 guests that use big real mode.

   

 Why do that unconditionally, instead of only when in a big-real-mode 
 state?

It can be.  It's probably easier from a development perspective to make 
it unconditional and then to flush out all the necessary instructions.

Regards,

Anthony Liguori


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-26 Thread Avi Kivity
Mohammed Gamal wrote:
  Why do that unconditionally, instead of only when in a big-real-mode state?
 

 Is big-real-mode the only state where we have problems?
   

In general, we need to emulate whenever we are in a VT-unfriendly state, 
where that is defined as guest state that fails the guest state checks 
defined by section 22.3.1 of volume 3B of the Intel software development 
manual, checks on the guest state area, when that state is legal in a 
real processor.  To date, we have encountered only two instances of such 
VT-unfriendly states:

- big real mode, where segment limits are not exactly 0x
- protected mode transitions, where cs.rpl !=ss.rpl for a brief while

There may well be more, as we remove the various hacks currently in 
place, and as we expand the envelope to support hybrid 16/32 bit guests 
like Windows 3.1 and Windows 95.

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


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-25 Thread Guillaume Thouvenin
On Thu, 24 Apr 2008 11:05:39 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:

 The first stage is to detect vmentry failures and run x86_emulate() for 
 a single instruction.  If you look at the mailing list, you'll see 
 patches from myself and Guillaume.  This should be enough to allow most 
 Ubuntu installer CDs to work under KVM.

Howdy, 

  Here is the last patch I have. It can detects a vmentry failure and it
emulates one instruction. I added the emulation of several instructions
like ljmp, mov Sreg, reg, mov reg, Sreg... The problem I'm
working on is that once I entered in emulation of real mode I do not
manage to recover a VMX friendly state (in my case cs.rpl ==
ss.rpl). So I emulate more and more instructions. 

  I added a trace to see instructions that are emulated (emulation of
0xa8 is in progress so it currently fails):

[60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18
[60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
[60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
[60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
[60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
[60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
[60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
[60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00
[60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0
[60108.348973] emulation at (46e71) rip 6e31: 8e c0 8e e0
[60108.396965] emulation at (46e73) rip 6e33: 8e e0 8e e8
[60108.445002] emulation at (46e75) rip 6e35: 8e e8 58 66
[60108.489021] emulation at (46e77) rip 6e37: 58 66 9d 66
[60108.521028] emulation at (46e78) rip 6e38: 66 9d 66 c3
[60108.552979] emulation at (46e7a) rip 6e3a: 66 c3 66 9c
[60108.581048] emulation at (40e2a) rip dea: be 29 0a 00
[60108.613033] emulation at (40e2f) rip def: e8 41 12 00
[60108.644970] emulation at (42075) rip 2035: c6 05 84 07
[60108.673038] emulation at (4207c) rip 203c: e8 18 01 00
[60108.705039] emulation at (42199) rip 2159: 31 c0 80 3d
[60108.736998] emulation at (4219b) rip 215b: 80 3d 86 07
[60108.765041] emulation at (421a2) rip 2162: 74 01 26 ac
[60108.797044] emulation at (421a5) rip 2165: ac c3 80 3d
[60108.829033] emulation at (421a6) rip 2166: c3 80 3d 86
[60108.857068] emulation at (42081) rip 2041: 09 c0 0f 84
[60108.889053] emulation at (42083) rip 2043: 0f 84 0f 01
[60108.921054] emulation at (42198) rip 2158: c3 31 c0 80
[60108.949076] emulation at (40e34) rip df4: 26 66 ff 35
[60108.981077] emulation at (40e3c) rip dfc: 66 8f 05 d0
[60109.013011] emulation at (40e43) rip e03: a1 b4 00 00
[60109.041079] emulation at (40e48) rip e08: 26 8a 40 03
[60109.073039] emulation at (40e4c) rip e0c: a8 01 74 4c
[60109.101078] emulation failed (vmentry failure) rip e0c a8 01 74 4c


So as we can see the first emulated instruction is the ljump and after
we emulate gfxboot loader instruction. I suspect a problem with an
update of SS segment or something like that in instructions that I
emulate.

I paste the patch. Don't worry about the last modification of the two
header files it's not related to real mode emulation.


Regards,
Guillaume

---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..2c4c14d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1183,7 +1183,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
fix_pmode_dataseg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
 
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
 
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2323,6 +2325,53 @@ static int handle_task_switch(struct kvm_vcpu *vcpu, 
struct kvm_run *kvm_run)
return kvm_task_switch(vcpu, tss_selector, reason);
 }
 
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+   u16 ss, cs;
+   u8 opcodes[4];
+   unsigned long rip = vcpu-arch.rip;
+   unsigned long rip_linear;
+
+   ss = vmcs_read16(GUEST_SS_SELECTOR);
+   cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+   if ((ss  0x03) != (cs  0x03)) {
+   int err;
+
+#if 0
+   printk(KERN_INFO vmentry failure because ss.cpl != cs.cpl\n);
+#endif
+   rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+   emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+   printk(KERN_INFO emulation at (%lx) rip %lx: %02x %02x %02x 
%02x\n,
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2], 
opcodes[3]);
+   err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+   switch (err) {
+   case EMULATE_DONE:
+#if 0
+   printk(KERN_INFO successfully emulated instruction\n);
+#endif
+   return 1;
+   case EMULATE_DO_MMIO:
+   printk(KERN_INFO 

Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-25 Thread Avi Kivity
Guillaume Thouvenin wrote:
 On Thu, 24 Apr 2008 11:05:39 -0500
 Anthony Liguori [EMAIL PROTECTED] wrote:

   
 The first stage is to detect vmentry failures and run x86_emulate() for 
 a single instruction.  If you look at the mailing list, you'll see 
 patches from myself and Guillaume.  This should be enough to allow most 
 Ubuntu installer CDs to work under KVM.
 

 Howdy, 

   Here is the last patch I have. It can detects a vmentry failure and it
 emulates one instruction. I added the emulation of several instructions
 like ljmp, mov Sreg, reg, mov reg, Sreg... The problem I'm
 working on is that once I entered in emulation of real mode I do not
 manage to recover a VMX friendly state (in my case cs.rpl ==
 ss.rpl). So I emulate more and more instructions. 

   I added a trace to see instructions that are emulated (emulation of
 0xa8 is in progress so it currently fails):

 [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18
   

Here cs.rpl == cpl == 0

 [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
 [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
 [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
 [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
 [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
 [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
 [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00
   

mov $8, %eax

 [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0
   
mov %eax, %ss

Here, ss.rpl == 0

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


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-25 Thread Guillaume Thouvenin
On Fri, 25 Apr 2008 09:51:04 +0300
Avi Kivity [EMAIL PROTECTED] wrote:

  [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18

 
 Here cs.rpl == cpl == 0
 
  [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
  [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
  [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
  [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
  [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
  [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
  [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00

 
 mov $8, %eax
 
  [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0

 mov %eax, %ss
 
 Here, ss.rpl == 0

Yes, thus ss.rpl should be equal to cs.rpl (both equal to 0) and we
should be in VMX friendly state. Mmmh, that means I made a mistake in
the implementation of 0xb8 or 0x8e instruction. I'm investigating,
thanks for your help.

Best regards,
Guillaume

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-24 Thread Mohammed Gamal
Hi,
My Project proposal Improving and Stabilizing Real-Mode Support for
Intel Hosts has been accepted into Google Summer of Code under the
Linux Foundation. You may have a look at  the proposal abstract here:
http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E
.

Any pointers on where to start, what would you like to see done, and
any other comments and suggestions would greatly be appreciated.

Regards,
Mohammed

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-24 Thread Mohammed Gamal
On Thu, Apr 24, 2008 at 5:47 PM, Avi Kivity [EMAIL PROTECTED] wrote:
 Mohammed Gamal wrote:

  Hi,
  My Project proposal Improving and Stabilizing Real-Mode Support for
  Intel Hosts has been accepted into Google Summer of Code under the
  Linux Foundation. You may have a look at  the proposal abstract here:
  http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E
  .
 
 
 

  Excellent! It's an area where kvm has been lagging for a long time.



  Any pointers on where to start, what would you like to see done, and
  any other comments and suggestions would greatly be appreciated.
 
 

  It boils down to:

  - removing the current hacks (fix_rmode_dataseg etc)
  - identifying when the vcpu state does not allow using VT
  (when a segment limit != 65535, or when ss.rpl != cpl in protected mode)
  - can be done by intercepting vmentry failures
  - or by looking at the state directly when entering real mode or protected
 mode
  - trapping to the emulator in this case
  - extending the emulator to support any opcodes which we will encounter
 when doing this

  Guillaume Thouvenin (copied) has been working on this lately.

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



Thanks for the feedback, this has been really helpful. I also saw
Guillame's work and I'd be very much willing to cooperate :).

Regards,
Mohammed

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-24 Thread Anthony Liguori
Mohammed Gamal wrote:
 Hi,
 My Project proposal Improving and Stabilizing Real-Mode Support for
 Intel Hosts has been accepted into Google Summer of Code under the
 Linux Foundation. You may have a look at  the proposal abstract here:
 http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E
 .

 Any pointers on where to start, what would you like to see done, and
 any other comments and suggestions would greatly be appreciated.
   

We have a two stage plan to address real-mode on Intel systems.  Both 
involve using x86_emulate() to emulate 16-bit (and 32-bit) instructions 
that VT cannot handle.

The first stage is to detect vmentry failures and run x86_emulate() for 
a single instruction.  If you look at the mailing list, you'll see 
patches from myself and Guillaume.  This should be enough to allow most 
Ubuntu installer CDs to work under KVM.  In this case, the CDs are using 
a version of GFXBOOT that doesn't use big real mode, but still relies on 
an undefined architectural aspect that VT doesn't support.

The second stage is to use a loop of x86_emulate() to run all 16-bit 
code (instead of using vm86 mode).  This will allow us to support guests 
that use big real mode.

The best place to start is probably to try out some of the patches on 
the list, and get familiar with the GFXBOOT assembly routines.  There's 
a #kvm in FreeNode, that's a good place to start if you're having 
trouble getting started.

Regards,

Anthony Liguori

 Regards,
 Mohammed

 -
 This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
 Don't miss this year's exciting event. There's still time to save $100. 
 Use priority code J8TL2D2. 
 http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
 ___
 kvm-devel mailing list
 kvm-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/kvm-devel
   


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project

2008-04-24 Thread Avi Kivity
Mohammed Gamal wrote:
 Hi,
 My Project proposal Improving and Stabilizing Real-Mode Support for
 Intel Hosts has been accepted into Google Summer of Code under the
 Linux Foundation. You may have a look at  the proposal abstract here:
 http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E
 .

   

Excellent! It's an area where kvm has been lagging for a long time.

 Any pointers on where to start, what would you like to see done, and
 any other comments and suggestions would greatly be appreciated.
   

It boils down to:

- removing the current hacks (fix_rmode_dataseg etc)
- identifying when the vcpu state does not allow using VT
(when a segment limit != 65535, or when ss.rpl != cpl in protected mode)
- can be done by intercepting vmentry failures
- or by looking at the state directly when entering real mode or 
protected mode
- trapping to the emulator in this case
- extending the emulator to support any opcodes which we will encounter 
when doing this

Guillaume Thouvenin (copied) has been working on this lately.

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


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel