Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1542772

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

From Vitaly Kuznetsov <vkuznets@redhat.com>
Newsgroups linux.kernel
Subject Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel
Date 2016-12-15 15:40 +0100
Message-ID <sOFmp-6RD-9@gated-at.bofh.it> (permalink)
References (2 earlier) <sOBC9-4DI-9@gated-at.bofh.it> <sOBVw-4Kn-23@gated-at.bofh.it> <sODNE-5R6-19@gated-at.bofh.it> <sOEgG-6fO-15@gated-at.bofh.it> <sOEJH-6pt-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

Olaf Hering <olaf@aepfle.de> 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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 11:40 +0100
  Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 11:40 +0100
    Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 11:40 +0100
      Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 12:00 +0100
    Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 12:00 +0100
      Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 14:00 +0100
        Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 14:30 +0100
          Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 15:00 +0100
            Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 15:40 +0100
              RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-16 02:00 +0100
          Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 16:20 +0100

csiph-web