I don't know who would own the "official" fix. It's possible that VMware might be able to simply change their code to send a different type of "bus busy" signal to the VMware, however, that would likely require a significant amount of testing.
Another solution would of course be for LSI Logic to back out this code, however, I suspect that the new code may technically be the more "correct" code, it just happens to have behavior we probably don't want in a VM (although perhaps in a cluster case, we still may want this behavior).
Another option would be for VMware to ship their own custom version of the mptscsih driver just like they always shipped a BusLogic driver with ESX 2.5.x. This is my least favorite approach, but somehow the one I think most likely because it's probably the only one VMware can control that offers no risk to their other supported environments.
Of course, they may also continue to simply attempt to ignore the situation, that appears to be the current strategy, claim every system that has this problem is not on the HCL and ignore it. Never mind the fact that it can be duplicated on local disk, and even on "certified" SAN hardware (I have reproduced it on our Fiber Channel CX400 arrays, although it is much more difficult to trigger).
I guess we will see. Our production systems with my current "workaround" have both made 8 days of uptime since I installed these slightly modified drivers. The previous record for one of the systems was 7 days, and usually only 2-3 days of normal load.
Later,
Tom
