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

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

[Jamie Kirkpatrick]

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.

Thanks in advance.

--
Jamie Kirkpatrick
07818 422311

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

[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

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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 <setjmp.h>

  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

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

[Avi Kivity]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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 <setjmp.h>
>
>   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
000000000266b000: 0x00000000 0x00000000 0x00000000 0x00000000
000000000266b010: 0x00000000 0x00209b00 0x0000ffff 0x00cf9300
000000000266b020: 0x0000ffff 0x00cffb00 0x0000ffff 0x00cff300
000000000266b030: 0x00000000 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.

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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

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

[Avi Kivity]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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.

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

[Avi Kivity]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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.

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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=00230000 ECX=61108b28 EDX=0043fea7
ESI=00000014 EDI=00000000 EBP=0022c518 ESP=0022c4f4
EIP=610935e2 EFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =002b 0000000000000000 ffffffff 00c0f300
CS =0023 0000000000000000 ffffffff 00c0fb00
SS =002b 0000000000000000 ffffffff 00c0f300
DS =002b 0000000000000000 ffffffff 00c0f300
FS =0053 000000007efdd000 00000fff 0040f300
GS =002b 000000007efdb000 ffffffff 00c0f300
LDT=0000 0000000000000000 0000ffff 00000000
TR =0040 fffff800004e8070 00000068 00008b00
GDT=     fffff800004e7000 0000006f
IDT=     fffff800004e7070 00000fff
CR0=80050031 CR2=000007ff7dd13000 CR3=000000002d62c000 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=000000007ffe00300000000000160014 XMM07=00000000000000000000000000000000
(qemu) x/28x 0xfffff800004e7000
fffff800004e7000: 0x00000000 0x00000000 0x00000000 0x00000000
fffff800004e7010: 0x00000000 0x00209b00 0x0000ffff 0x00cf9300
fffff800004e7020: 0x0000ffff 0x00cffb00 0x0000ffff 0x00cff300
fffff800004e7030: 0x00000000 0x0020fb00 0x00000000 0x00000000
fffff800004e7040: 0x80700068 0x00008b4e 0xfffff800 0x00000000
fffff800004e7050: 0xd0000fff 0x7e40f3fd 0x00000000 0x00000000
fffff800004e7060: 0x0000ffff 0x00cf9b00 0x00000000 0x00000000

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

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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=00230000 ECX=61108b28 EDX=0043fea7
> ESI=00000014 EDI=00000000 EBP=0022c518 ESP=0022c4f4
> EIP=610935e2 EFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
> ES =002b 0000000000000000 ffffffff 00c0f300
> CS =0023 0000000000000000 ffffffff 00c0fb00
> SS =002b 0000000000000000 ffffffff 00c0f300
> DS =002b 0000000000000000 ffffffff 00c0f300
> FS =0053 000000007efdd000 00000fff 0040f300
> GS =002b 000000007efdb000 ffffffff 00c0f300
> LDT=0000 0000000000000000 0000ffff 00000000
> TR =0040 fffff800004e8070 00000068 00008b00
> GDT=     fffff800004e7000 0000006f
> IDT=     fffff800004e7070 00000fff
> CR0=80050031 CR2=000007ff7dd13000 CR3=000000002d62c000 CR4=000006f8
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
> DR6=00000000ffff0ff0 DR7=0000000000000400
> FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
> XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
> XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
> XMM06=000000007ffe00300000000000160014 XMM07=00000000000000000000000000000000
> (qemu) x/28x 0xfffff800004e7000
> fffff800004e7000: 0x00000000 0x00000000 0x00000000 0x00000000
> fffff800004e7010: 0x00000000 0x00209b00 0x0000ffff 0x00cf9300
> fffff800004e7020: 0x0000ffff 0x00cffb00 0x0000ffff 0x00cff300
> fffff800004e7030: 0x00000000 0x0020fb00 0x00000000 0x00000000
> fffff800004e7040: 0x80700068 0x00008b4e 0xfffff800 0x00000000
> fffff800004e7050: 0xd0000fff 0x7e40f3fd 0x00000000 0x00000000
> fffff800004e7060: 0x0000ffff 0x00cf9b00 0x00000000 0x00000000
>   

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.


[-- Attachment #2: gs.c --]
[-- Type: text/x-csrc, Size: 343 bytes --]

#include <stdio.h>

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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

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

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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.


[-- Attachment #2: gs.c --]
[-- Type: text/x-csrc, Size: 371 bytes --]

#include <stdio.h>

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

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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.


[-- Attachment #2: gs.c --]
[-- Type: text/x-csrc, Size: 371 bytes --]

#include <stdio.h>

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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)

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

[Matteo Frigo]

Matteo Frigo <athena@fftw.org> writes:

> Avi Kivity <avi@redhat.com> 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 <http://gnu.org/licenses/gpl.html>
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 0x77d40000 not found.
Error: dll starting at 0x77d40000 not found.
Error: dll starting at 0x77c20000 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 <main+77>:	mov    %gs:0x30,%esi
(gdb) p/x $gs
$1 = 0x2b
(gdb) 

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

[Avi Kivity]

Matteo Frigo wrote:
> Matteo Frigo <athena@fftw.org> writes:
>
>   
>> Avi Kivity <avi@redhat.com> 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 <http://gnu.org/licenses/gpl.html>
> 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 0x77d40000 not found.
> Error: dll starting at 0x77d40000 not found.
> Error: dll starting at 0x77c20000 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 <main+77>:	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.

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

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

Avi Kivity wrote:
> Matteo Frigo wrote:
>> Matteo Frigo <athena@fftw.org> writes:
>>
>>  
>>> Avi Kivity <avi@redhat.com> 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 
>> <http://gnu.org/licenses/gpl.html>
>> 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 0x77d40000 not found.
>> Error: dll starting at 0x77d40000 not found.
>> Error: dll starting at 0x77c20000 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 <main+77>:    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.


[-- Attachment #2: cygwin-fix.patch --]
[-- Type: text/x-patch, Size: 397 bytes --]

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

[Matteo Frigo]

Avi Kivity <avi@redhat.com> 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

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

[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.

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

[Avi Kivity]

Matteo Frigo wrote:
> Matteo Frigo <athena@fftw.org> writes:
>
>   
>> Avi Kivity <avi@redhat.com> 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 <http://gnu.org/licenses/gpl.html>
> 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 0x77d40000 not found.
> Error: dll starting at 0x77d40000 not found.
> Error: dll starting at 0x77c20000 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 <main+77>:	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.