Kernel panics like this (ones in the kernel itself, not in VMware code) are painfully hard to debug without reproducing it on a system at VMware. (And, from the specs you gave in your original post, 8-CPU 9GB Mac machines aren't all that common!).
Looking at the error and the backtrace involved, it looks like one CPU is doing a normal cleanup which requires communication with the other CPUs, and that cross-cpu communication times out. This tells me two things: (1) it's a race condition, depending on the random scheduling of two of your eight CPUs - and thus extremely hard to reproduce, and (2) the useful information that would tell us what code is misbehaving (and not answering the communication fast enough) is on a different CPU which is not contained in this backtrace. (Nor is there a way for you to get at the information).
(The backtrace is almost the same as this one: http://lists.apple.com/archives/ata-scsi-dev/2006/Dec/msg00000.html - which basically says some code somewhere else is hanging on to a CPU for too long.)
We'll have to hope we can reproduce this in-house. The only workaround I can suggest is turning off a bunch of the CPU cores; I know that's not realistic in your case. Your machine is just too powerful 
.
Doesn't VMWare install some sort of hypervisor down at the OS level? Doesn't it have the capability of adversely affecting the OS? While I realize there are kernel panics that look similar to one another, the fact that I have never seen a kernel panic without VMWare running, but have with Fusion running, leads me to believe it's Fusion related. I have provided
I guess in the mean time I could do something like set the # of CPU cores on the XP VM to 1 instead of 2 (I've already shut off DirectX). Should that help at all?
So far, knock on wood, I'm going on almost 2 days with no crashes with both VMs running. Perhaps I should be quiet now lest I jinx it. 