Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-01-22 Thread Avi Kivity

Jamie Kirkpatrick wrote:

All

This is my first post to the list but this seems to be the only place
I can get this problem to be looked at by hopefully the correct
people: I've bounced it around in #kvm on freenode and we've all
agreed its a development issue / bug that needs looking at.

Anyway, without further ado: my machine is a Core 2 Due Quad Core
based box running Debian Lenny and a 2.6.27 kernel as the host OS.  I
am using KVM-82 right now and track all current releases of the KVM
code.

The issue I have run into seems to be very specific to the hardware
setup I have and the fact that I'm running this version of Windows
under virtualization.  I have been trying for some time to get Git to
work under this OS and for one reason or another I was trying the
cygwin based install.  Problems started appearing as soon as I install
cygwin, and during the installation process even: various post-install
config scripts crash and I get the usual windows JIT debugger window
popping up etc.

Upon further investigation I have tracked the problem down to a
problem with Cygwin bash's builtin "test" implementation ( the []
syntax in shell scripting ).  I can cause the crash by simply invoking
this syntax from a command line.  This problem has been noted before
and has been posted about elsewhere: first on the cygwin list, and
then after on the Xen list.  Everyone seems to agree that based on
more extensive testing from other people that this is being caused by
something in the virtualzation stack.

Two messages of note are:

http://sourceware.org/ml/cygwin/2008-01/msg00582.html
http://www.nabble.com/Xen-3.2.1---Win-2003-2008-Server-64-bit-guests:-cygwin-bash-builtin-%22test%22-crashes-td19001336.html

I've spent a long time trying to track this down: I've tried various
versions of KVM and have tried playing around with windows lots as
well.  No luck.  I'm lost on this but it seems to me that this just
should not happen and if there is a bug in the way Xen and KVM treat
things then it needs fixing...hence the post.

If someone wants to try and squash / identify this bug further I'm
availible as a tester:  I am a c++ developer by day but I don't know
the KVM code or how you go about debugging it.  If someone can prime
me in that direction perhaps I could look at it as well.

Anyway, anything I can do to help and I will.
  


I tried to track this down.  Apparently the guest clobbers gs during the 
exit routine.


Since it happens in the guest, it's a little difficult to track down.  
It can be done using the guest debugger, in this way:


- start bash in the debugger
- stop the program
- add a watchpoint to break when the value of gs:[0x30] changes
- single-step the program until the watchpoint triggers

However, my Windows debugging skills are pretty much nonexistent.  Can 
you guide me through this?  I'm using windbg.


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-05 Thread Matteo Frigo
Avi Kivity  writes:

> - add a watchpoint to break when the value of gs:[0x30] changes

It seems that the problem can be reproduced by compiling the following
simple program using cygwin's gcc.  The program crashes on w2k3-amd64
on kvm-83 on core2-duo, and it does not crash on the same w2k3-amd64
installation on kvm-83 on AMD Phenom.

  #include 

  jmp_buf env;
  main()
  {
   if(setjmp(env)) return;
   longjmp(env, 1);
  }

The problem seems to be in the instruction ``mov gs,ax'' (Intel
syntax) in the longjmp() code.  If I let the virtual machine execute
the instruction, the program crashes.  However, if I step over the
instruction using the vs2008 debugger, the program completes without
crashing.  Thus, I think that this is the instruction that Avi is
looking for, but I don't know how to proceed from here.

Hope this helps.
Cheers,
Matteo Frigo

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

- add a watchpoint to break when the value of gs:[0x30] changes



It seems that the problem can be reproduced by compiling the following
simple program using cygwin's gcc.  The program crashes on w2k3-amd64
on kvm-83 on core2-duo, and it does not crash on the same w2k3-amd64
installation on kvm-83 on AMD Phenom.

  #include 

  jmp_buf env;
  main()
  {
   if(setjmp(env)) return;
   longjmp(env, 1);
  }

The problem seems to be in the instruction ``mov gs,ax'' (Intel
syntax) in the longjmp() code.  If I let the virtual machine execute
the instruction, the program crashes.  However, if I step over the
instruction using the vs2008 debugger, the program completes without
crashing.  Thus, I think that this is the instruction that Avi is
looking for, but I don't know how to proceed from here.
  


I've decoded the global descriptor table for this, and I get:

(qemu) xp/14x 0x266b000
0266b000: 0x 0x 0x 0x
0266b010: 0x 0x00209b00 0x 0x00cf9300
0266b020: 0x 0x00cffb00 0x 0x00cff300
0266b030: 0x 0x0020fb00

The entry for gs is at offset 0x28, and has base set to 0, which is 
consistent with the crash.


Can you rerun on AMD, but set add npt=0 as a kvm-amd module parameter?  
This will determine if this is an mmu bug or kvm-intel bug.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

Can you rerun on AMD, but set add npt=0 as a kvm-amd module parameter?
This will determine if this is an mmu bug or kvm-intel bug.



AMD works fine with npt=0, both cygwin and my setjmp()/longjmp() test
program.  dmesg confirms that nested paging is disabled.
  


So it isn't the mmu.

I'm a a little far latency-wise from an AMD host.  Can you run this 
experiment on AMD (-monitor stdio will help):


- run a cygwin program in an infinite loop (while :; do :; done is 
sufficient)

- 'info registers', look at gdt
- 'x/28x 0x$GDT'

I'm interested in offset 0x28, but please provide the whole thing for 
sanity checking.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

Can you rerun on AMD, but set add npt=0 as a kvm-amd module parameter?
This will determine if this is an mmu bug or kvm-intel bug.



AMD works fine with npt=0, both cygwin and my setjmp()/longjmp() test
program.  dmesg confirms that nested paging is disabled.
  


So it isn't the mmu.

I'm a a little far latency-wise from an AMD host.  Can you run this 
experiment on AMD (-monitor stdio will help):


- run a cygwin program in an infinite loop (while :; do :; done is 
sufficient)

- 'info registers', look at gdt
- 'x/28x 0x$GDT'

I'm interested in offset 0x28, but please provide the whole thing for 
sanity checking.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Avi Kivity  writes:

> - run a cygwin program in an infinite loop (while :; do :; done is
> sufficient)
> - 'info registers', look at gdt
> - 'x/28x 0x$GDT'
>
> I'm interested in offset 0x28, but please provide the whole thing for
> sanity checking.

Here it is.  This is with npt=1, but npt=0 shows exactly the
same GDT.

(qemu) info registers
EAX=0022dad8 EBX=0023 ECX=61108b28 EDX=0043fea7
ESI=0014 EDI= EBP=0022c518 ESP=0022c4f4
EIP=610935e2 EFL=0202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =002b   00c0f300
CS =0023   00c0fb00
SS =002b   00c0f300
DS =002b   00c0f300
FS =0053 7efdd000 0fff 0040f300
GS =002b 7efdb000  00c0f300
LDT=   
TR =0040 f84e8070 0068 8b00
GDT= f84e7000 006f
IDT= f84e7070 0fff
CR0=80050031 CR2=07ff7dd13000 CR3=2d62c000 CR4=06f8
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
FCW=037f FSW= [ST=0] FTW=00 MXCSR=
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06=7ffe003000160014 XMM07=
(qemu) x/28x 0xf84e7000
f84e7000: 0x 0x 0x 0x
f84e7010: 0x 0x00209b00 0x 0x00cf9300
f84e7020: 0x 0x00cffb00 0x 0x00cff300
f84e7030: 0x 0x0020fb00 0x 0x
f84e7040: 0x80700068 0x8b4e 0xf800 0x
f84e7050: 0xdfff 0x7e40f3fd 0x 0x
f84e7060: 0x 0x00cf9b00 0x 0x
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Avi Kivity  writes:

> Can you rerun on AMD, but set add npt=0 as a kvm-amd module parameter?
> This will determine if this is an mmu bug or kvm-intel bug.

AMD works fine with npt=0, both cygwin and my setjmp()/longjmp() test
program.  dmesg confirms that nested paging is disabled.

Regards,
Matteo Frigo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

- run a cygwin program in an infinite loop (while :; do :; done is
sufficient)
- 'info registers', look at gdt
- 'x/28x 0x$GDT'

I'm interested in offset 0x28, but please provide the whole thing for
sanity checking.



Here it is.  This is with npt=1, but npt=0 shows exactly the
same GDT.

(qemu) info registers
EAX=0022dad8 EBX=0023 ECX=61108b28 EDX=0043fea7
ESI=0014 EDI= EBP=0022c518 ESP=0022c4f4
EIP=610935e2 EFL=0202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =002b   00c0f300
CS =0023   00c0fb00
SS =002b   00c0f300
DS =002b   00c0f300
FS =0053 7efdd000 0fff 0040f300
GS =002b 7efdb000  00c0f300
LDT=   
TR =0040 f84e8070 0068 8b00
GDT= f84e7000 006f
IDT= f84e7070 0fff
CR0=80050031 CR2=07ff7dd13000 CR3=2d62c000 CR4=06f8
DR0= DR1= DR2= DR3= 
DR6=0ff0 DR7=0400

FCW=037f FSW= [ST=0] FTW=00 MXCSR=
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06=7ffe003000160014 XMM07=
(qemu) x/28x 0xf84e7000
f84e7000: 0x 0x 0x 0x
f84e7010: 0x 0x00209b00 0x 0x00cf9300
f84e7020: 0x 0x00cffb00 0x 0x00cff300
f84e7030: 0x 0x0020fb00 0x 0x
f84e7040: 0x80700068 0x8b4e 0xf800 0x
f84e7050: 0xdfff 0x7e40f3fd 0x 0x
f84e7060: 0x 0x00cf9b00 0x 0x
  


According to the GDT, gs:base will be zero after executing the 'mov gs' 
instruction (but gs:base is not zero prior, as seen in 'info 
registers').  This is the same info I get on Intel, so it seems the GDT 
is maintained correctly.


More questions:
- is the bad 'mov gs' instruction reached on AMD?  or is it avoided 
somehow?  What about bare metal?
- does the attached program fail when compiled and run in cygwin on an 
AMD host?
- does setjmp()/longjmp() come from the Windows run-time library, or 
from cygwin?


I note that ds, es, ss, and gs all contain the same selector, so I don't 
see how longjmp() can expect that gs.base will not be clobbered after 
executing 'mov gs'.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

#include 

int main()
{
unsigned short gs;
unsigned x;

asm ("mov %%gs, %0\n" : "=g"(gs));
asm ("movl %%gs:0x30, %0\n" : "=r"(x));

printf("gs: %x\n", gs);
printf("gs:0x30: %x\n", x);

asm ("mov %0, %%gs\n" : : "g"(gs));

printf("test\n");

asm ("movl %%gs:0x30, %0\n" : "=r"(x));

return 0;
}


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Avi Kivity  writes:

> More questions:
> - is the bad 'mov gs' instruction reached on AMD?  or is it avoided
> somehow?  What about bare metal?

The instruction is indeed reached on amd, and gs is 0x2b after
the instruction.  I don't know about bare metal.

> - does the attached program fail when compiled and run in cygwin on an
> AMD host?

The program runs as follows:

w2k3-64:/cygdrive/v$ gcc -O gs.c
w2k3-64:/cygdrive/v$ ./a.exe 
gs: 2b
gs:0x30: 7efdb000
test

> - does setjmp()/longjmp() come from the Windows run-time library, or 
> from cygwin?

The setjmp()/longjmp() is in the cygwin library /bin/cygwin1.dll .
bash calls longjmp() at the end of the expr built-in, which causes the
problem reported by the original poster.

I should also mention that, as an experiment, I have replaced the mov
gs,ax instruction with a couple of no-ops in cygwin1.dll, and cygwin
runs fine on Intel with this patch.

Regards,
Matteo Frigo

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

More questions:
- is the bad 'mov gs' instruction reached on AMD?  or is it avoided
somehow?  What about bare metal?



The instruction is indeed reached on amd, and gs is 0x2b after
the instruction.  I don't know about bare metal.

  

- does the attached program fail when compiled and run in cygwin on an
AMD host?



The program runs as follows:

w2k3-64:/cygdrive/v$ gcc -O gs.c
w2k3-64:/cygdrive/v$ ./a.exe 
gs: 2b

gs:0x30: 7efdb000
test

  
- does setjmp()/longjmp() come from the Windows run-time library, or 
from cygwin?



The setjmp()/longjmp() is in the cygwin library /bin/cygwin1.dll .
bash calls longjmp() at the end of the expr built-in, which causes the
problem reported by the original poster.

I should also mention that, as an experiment, I have replaced the mov
gs,ax instruction with a couple of no-ops in cygwin1.dll, and cygwin
runs fine on Intel with this patch.

  


That was going to be my next question :)

Right now I don't understand how cygwin's longjmp() is supposed to work 
at all, given that it clobbers gs.


Can you run the slightly modified gs.c (attached) and rerun on AMD?  The 
is to see if the runtime somehow restores gs.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

#include 

int main()
{
unsigned short gs;
unsigned x;

asm ("mov %%gs, %0\n" : "=g"(gs));
asm ("movl %%gs:0x30, %0\n" : "=r"(x));

printf("gs: %x\n", gs);
printf("gs:0x30: %x\n", x);

asm volatile ("mov %0, %%gs\n" : : "g"(gs));

asm volatile ("movl %%gs:0x30, %0\n" : "=r"(x));

printf("gs:0x30: %x\n", x);

return 0;
}


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Avi Kivity  writes:

  

More questions:
- is the bad 'mov gs' instruction reached on AMD?  or is it avoided
somehow?  What about bare metal?



The instruction is indeed reached on amd, and gs is 0x2b after
the instruction.  I don't know about bare metal.

  

- does the attached program fail when compiled and run in cygwin on an
AMD host?



The program runs as follows:

w2k3-64:/cygdrive/v$ gcc -O gs.c
w2k3-64:/cygdrive/v$ ./a.exe 
gs: 2b

gs:0x30: 7efdb000
test

  
- does setjmp()/longjmp() come from the Windows run-time library, or 
from cygwin?



The setjmp()/longjmp() is in the cygwin library /bin/cygwin1.dll .
bash calls longjmp() at the end of the expr built-in, which causes the
problem reported by the original poster.

I should also mention that, as an experiment, I have replaced the mov
gs,ax instruction with a couple of no-ops in cygwin1.dll, and cygwin
runs fine on Intel with this patch.

  


That was going to be my next question :)

Right now I don't understand how cygwin's longjmp() is supposed to work 
at all, given that it clobbers gs.


Can you run the slightly modified gs.c (attached) and rerun on AMD?  The 
is to see if the runtime somehow restores gs.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

#include 

int main()
{
unsigned short gs;
unsigned x;

asm ("mov %%gs, %0\n" : "=g"(gs));
asm ("movl %%gs:0x30, %0\n" : "=r"(x));

printf("gs: %x\n", gs);
printf("gs:0x30: %x\n", x);

asm volatile ("mov %0, %%gs\n" : : "g"(gs));

asm volatile ("movl %%gs:0x30, %0\n" : "=r"(x));

printf("gs:0x30: %x\n", x);

return 0;
}


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Avi Kivity  writes:

> Can you run the slightly modified gs.c (attached) and rerun on AMD?
> The is to see if the runtime somehow restores gs.

Crashes as follows:

w2k3-64:~$ ./a.exe 
gs: 2b
gs:0x30: 7efdb000
Segmentation fault (core dumped)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Matteo Frigo  writes:

> Avi Kivity  writes:
>
>> Can you run the slightly modified gs.c (attached) and rerun on AMD?
>> The is to see if the runtime somehow restores gs.
>
> Crashes as follows:
>
> w2k3-64:~$ ./a.exe 
> gs: 2b
> gs:0x30: 7efdb000
> Segmentation fault (core dumped)

A little bit more information:

w2k3-64:~$ gdb a.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(no debugging symbols found)
(gdb) r
Starting program: /home/athena/a.exe 
[New thread 1620.0x6dc]
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77c2 not found.
Error while mapping shared library sections:
/cygdrive/c/WINDOWS/SysWOW64/ntdll32.dll: No such file or directory.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New thread 1620.0x74c]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0040109d in main ()
(gdb) x/i $pc
0x40109d : mov%gs:0x30,%esi
(gdb) p/x $gs
$1 = 0x2b
(gdb) 
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Matteo Frigo  writes:

  

Avi Kivity  writes:



Can you run the slightly modified gs.c (attached) and rerun on AMD?
The is to see if the runtime somehow restores gs.
  

Crashes as follows:

w2k3-64:~$ ./a.exe 
gs: 2b

gs:0x30: 7efdb000
Segmentation fault (core dumped)



A little bit more information:

w2k3-64:~$ gdb a.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(no debugging symbols found)
(gdb) r
Starting program: /home/athena/a.exe 
[New thread 1620.0x6dc]

Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77c2 not found.
Error while mapping shared library sections:
/cygdrive/c/WINDOWS/SysWOW64/ntdll32.dll: No such file or directory.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New thread 1620.0x74c]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0040109d in main ()
(gdb) x/i $pc
0x40109d :   mov%gs:0x30,%esi
(gdb) p/x $gs
$1 = 0x2b
(gdb) 
  


Okay, at least this makes some little bit of sense.  On both Intel and 
AMD, 'mov gs' clobbers gs.base as expected.  On AMD, something further 
down the line (some syscall likely) restores gs.base, but on Intel it 
doesn't.  When we avoid the syscall, we get a crash on AMD as well.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

Matteo Frigo  writes:

  

Avi Kivity  writes:



Can you run the slightly modified gs.c (attached) and rerun on AMD?
The is to see if the runtime somehow restores gs.
  

Crashes as follows:

w2k3-64:~$ ./a.exe 
gs: 2b

gs:0x30: 7efdb000
Segmentation fault (core dumped)



A little bit more information:

w2k3-64:~$ gdb a.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(no debugging symbols found)
(gdb) r
Starting program: /home/athena/a.exe 
[New thread 1620.0x6dc]

Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77c2 not found.
Error while mapping shared library sections:
/cygdrive/c/WINDOWS/SysWOW64/ntdll32.dll: No such file or directory.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New thread 1620.0x74c]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0040109d in main ()
(gdb) x/i $pc
0x40109d :   mov%gs:0x30,%esi
(gdb) p/x $gs
$1 = 0x2b
(gdb) 
  


Okay, at least this makes some little bit of sense.  On both Intel and 
AMD, 'mov gs' clobbers gs.base as expected.  On AMD, something further 
down the line (some syscall likely) restores gs.base, but on Intel it 
doesn't.  When we avoid the syscall, we get a crash on AMD as well.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Avi Kivity wrote:

Matteo Frigo wrote:

Matteo Frigo  writes:

 

Avi Kivity  writes:

   

Can you run the slightly modified gs.c (attached) and rerun on AMD?
The is to see if the runtime somehow restores gs.
  

Crashes as follows:

w2k3-64:~$ ./a.exe gs: 2b
gs:0x30: 7efdb000
Segmentation fault (core dumped)



A little bit more information:

w2k3-64:~$ gdb a.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(no debugging symbols found)
(gdb) r
Starting program: /home/athena/a.exe [New thread 1620.0x6dc]
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77d4 not found.
Error: dll starting at 0x77c2 not found.
Error while mapping shared library sections:
/cygdrive/c/WINDOWS/SysWOW64/ntdll32.dll: No such file or directory.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New thread 1620.0x74c]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0040109d in main ()
(gdb) x/i $pc
0x40109d :mov%gs:0x30,%esi
(gdb) p/x $gs
$1 = 0x2b
(gdb)   


Okay, at least this makes some little bit of sense.  On both Intel and 
AMD, 'mov gs' clobbers gs.base as expected.  On AMD, something further 
down the line (some syscall likely) restores gs.base, but on Intel it 
doesn't.  When we avoid the syscall, we get a crash on AMD as well.




The attached patch fixes it for me.  Without this, rdmsr(KERNEL_GS_BASE) 
reads a stale value, which presumably Windows later writes back.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

diff --git a/kernel/x86/vmx.c b/kernel/x86/vmx.c
index 7507ce2..048460d 100644
--- a/kernel/x86/vmx.c
+++ b/kernel/x86/vmx.c
@@ -910,6 +910,7 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
 		data = vmcs_readl(GUEST_SYSENTER_ESP);
 		break;
 	default:
+		vmx_load_host_state(vcpu);
 		msr = find_msr_entry(to_vmx(vcpu), msr_index);
 		if (msr) {
 			data = msr->data;


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Matteo Frigo
Avi Kivity  writes:

> + vmx_load_host_state(vcpu);

Works here as well (on intel).  

(On kvm-83, gcc complains about passing argument 1 of
'vmx_load_host_state' from incompatible pointer type.)

Thanks for the terrific support.  kvm rocks!

Regards,
Matteo Frigo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

2009-02-13 Thread Avi Kivity

Matteo Frigo wrote:

(On kvm-83, gcc complains about passing argument 1 of
'vmx_load_host_state' from incompatible pointer type.)
  


Yes, should be to_vmx(vcpu).  Same value anyway so it works.



Thanks for the terrific support.  kvm rocks!
  


Thanks for the debugging help.  kvm users rock!

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html