Hello J.F.V, please let me address your questions:

> is there anyway to know where the code crash using the vmware coredump file (or another debug option ?)

If you get a stack fault (that technically is triple-fault), then yes. If you are using beta build, or release build with "debug=true" then adding the following

option to config file will make your VM suspend at the moment of triple-fault:

    monitor.suspend_on_triplefault=true

Then if you resume the VM by passing one more option on the command line, debugger will get activated before the instruction is executed, just at the point of the triple-fault:

     .../vmware -s monitor_control.enable_guestdebugonstart=true MyVM.vmx

You should be able to attach debugger and take a look at memory/registers/etc. If this fails for any reason, take a look at vmware.log file after VM gets  suspended on a triple-fault, there should be register dump at the end of the log. It may help you find location of the code that caused triple-fault.

Both options are undocumented and unsupported, but I'll try to help if they do not work.

> Is it possible that debugging into vmware change rights on memory (just like debugging a userland application with gdb usually does). More generally, where can I get more information about the vmware gdb stub ?

Debug stub does not change Guest-visible memory protection. If you use "normal" breakpoints, stub will put "int3" in the Guest memory. With debugStub.hideBreakpoints=1, it is practically invisible. One exception - and the one that frequently masks triple faults - is this: when breakpoint hits (no matter if hidden or not), or when you single-step with the stub, we are flushing hardware TLB. If you happen to have a stale mapping in the TLB, then it could explain why you are getting stack-faults without stub, but do not get them with it. Just to be sure, you may want to try flushing TLB after all page table modifications in your kernel.

We do not  share that much information about internals of debug stub. If you have access to our Academics Program, or if your employer is part of our Community Source, then you can take a look at sources and contact me and other developers. Otherwise, the best way to find out is to be hired by VMware

> is there any other known issue (vmware or other) about executing such code, that would explain the difference of results between debugging into vmware and just letting it run ?

I  think I addressed this question above: stale TLB mappings in Guest kernel would be my best guess. I hope this helps.

Sincerely,

Vyacheslav (Slava) Malyugin

Hi J.F.V. I double-checked the sources for 6.0.3, and the options should work. I guess something is wrong with my assumption about the fault that your VM is getting. Is it possible that you added options to the .vmx file, and then restored from snapshot? Snapshot restore overwrites the values in configuration file. Do you  see all options in the vmware.log after the crash? Could you paste portion of the log a few dozen lines before and after message informing about "stack fault"? Thank you.

Sincerely,

Vyacheslav (Slava) Malyugin

I was trying to test this feature by enabling

        debug=true

        monitor.suspend_on_triplefault=true

in the .vmx file for the VM.

Manually induced kernel crash still prints the stack trace to the console

and doesn't suspend the VM.

What we would like to do is

    (1) guest VM should suspend on a kernel fault

    (2) we would like to connect to this VM from thru kgdb after resuming the guest

Today it looks like there can be only one gdbserver listener on vm management

network at vmnet gateway:8864 for a 64-bit guest.

Will the above sequence of triple fault suspend, resume, connect thru kgdb

still work if there are multiple guest VMs started

on the same vm management network on the same hypervisor with the following lines

in the .vmx file

  debugStub.listen.guest64 ="TRUE"

  debugStub.listen.guest64.remote ="TRUE"

  debugStub.hidebreakpoints = "TRUE"

  monitor.debugOnStartGuest64 = "TRUE"

Thanks,

kvc