Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

[Vitaly Kuznetsov]

Olaf Hering <olaf@xxxxxxxxx> writes:

> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
>> vmbus_wait_for_unload() may be receiving a message (not necessarily the
>> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
>> CPU it runs and in this case wrmsrl() makes sense. In other cases it
>> does nothing (neither good nor bad).
>
> If that other cpu has interrupts disabled it may not process a pending
> msg (the response may be stuck in the host queue?), and the loop can not
> kick the other cpus queue if a wrmsrl is just valid for the current cpu.
> If thats true, the response will not arrive in the loop.
>

In case interrupts get permanently disabled on the CPU which is supposed
to receive the CHANNELMSG_UNLOAD_RESPONSE message *and* there is some
other message pedning in the slot for that CPU we'll hang. We may try to
overcome this by sending NMIs but this is getting more and more
complicated...

I'd like to see a simple fix from Hyper-V host team: always deliver
CHANNELMSG_UNLOAD_RESPONSE reply to the cpu which sent CHANNELMSG_UNLOAD
request. This would allow us to remove all the craziness.

-- 
  Vitaly