Re: SVM VMRUN Weirdness

BTW, I never tried it with real AMD SVM hardware so I don’t know if Bochs is right here or not.

In theory, when in real mode the base is calculated directly from segment index and therefore not necessary should be in the VMCB so Bochs might be wrong.

Do you have the real AMD machine to try ?

 

Stanislav

 

From: [email protected] [mailto:[email protected]] 
Sent: Thursday, February 21, 2013 9:43 AM
To: [email protected]
Subject: Re: [Bochs-developers] SVM VMRUN Weirdness

 

Hi,

As I suspected, the problem was mine.  Being that I have coded mostly for protected mode, I was not aware that I needed to maintain the the descriptor data for each segment register in real mode.  I basically set all of the descriptors to all zeroes (except for the attribute) in the VMCB.  I have since learned by debugging BOCHS enough, that I need to set the base for each descriptor even in real mode.

I hope I haven't wasted anyone's time.  My apologies if I have.

Regards,

Chris



  _____  

From: [email protected]
To: [email protected]
Sent: Tuesday, February 19, 2013 12:44:52 PM
Subject: [Bochs-developers] SVM VMRUN Weirdness

Hi,

I have run into an issue with (I think) the bochs SVM functionality.  In debugging some new code, I found that when I step through a VMRUN call (first guest instructions executed), everything functions as expected. (see VMRun-Step.txt attached)  However if I turn trace on and don't step through, something odd happens. (see VMRun-Trace.txt also attached)

Regarding this code in the attached files:
0000:7C00    JMP +60
...
...
0000:7C36    cli

If I step through VMRUN, the first guest instruction executed is 0000:7C00, as it should be.  Then the 2nd instruction executed is 0000:7C36, also as it should be.

However, if I trace through VMRUN, the next instruction executed says it is at 0000:7C00 and is JMP +60, but then the next instruction executed is 0000:7C01.  This is the problem.  In my case 7C01 has an invalid opcode (0x3c90) so I can verify that tracing executes 7C01 while stepping doesn't.

I tried to track down the problem but haven't yet fully come to understand the instruction execution functionality, especially the prefetching.  However on a whim I did hack a fix in SVM.cc by setting async_event=1 unconditionally just before the call to handleCpuContextChange.  Note that I didn't do so because I knew what async_event would do ... it was just a wild guess.

After that change, when I run the modified bochs code, both stepping and tracing execute instruction #2 at 7C36.

But there's more, and it could be related.  With the "problem fixed" I then added code to my program to process intercepted interrupts from the guest.  So when the guest calls, for example, Int 13, I intercept it, put the guest Flags:CS:IP on the stack, decrement the SP, and point the guest at the vector CS:IP via the VMCB.  But when all my hypervisor work is done and VMRUN is called, the wrong guest code is executed.  In this case the debugger *says* that f000:e3fe is being executed, but the logical addy to the left of the segmented address says: [0x000000000000e3fe]

QUOTE:
(0) [0x00000000000502da] 0008:00000000000002da (unk. ctxt): vmrun rax                 ; 0f01d8
00016993704i[XGUI ] Mouse capture off
<bochs:30> s
Next at t=16993705
(0) [0x000000000000e3fe] f000:e3fe (unk. ctxt): add byte ptr ds:[bx+si], al ; 0000

I know for a fact that I populated the CS in the VMCB correctly, and it shows in the segmented address.

I am not sure that there is any relation between the two issues.  After all, the hack for the first issue doesn't fix the 2nd.  And no, the hack didn't CAUSE the 2nd issue.  I verified that by removing the hack and stepping through the code until I hit the line above. (f000:e3fe).  It still says:

(0) [0x000000000000e3fe] f000:e3fe (unk. ctxt): add byte ptr ds:[bx+si], al ; 0000

If someone can point me in the right direction, I'd be glad to help track down the issue(s) ... if they are indeed issues and not some problems with my code.  I've been looking at the bochs code quite a bit but it takes time to figure out how each element works.

Thanks,

Chris


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
bochs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bochs-developers

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

_______________________________________________
bochs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bochs-developers