Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758094AbcLON2O (ORCPT ); Thu, 15 Dec 2016 08:28:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35210 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757627AbcLON2M (ORCPT ); Thu, 15 Dec 2016 08:28:12 -0500 From: Vitaly Kuznetsov To: Olaf Hering Cc: kys@microsoft.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel References: <20161207085110.GC1618@aepfle.de> <87r3594hef.fsf@vitty.brq.redhat.com> <20161215103402.GA6336@aepfle.de> <87mvfx4g4y.fsf@vitty.brq.redhat.com> <20161215125139.GC6336@aepfle.de> Date: Thu, 15 Dec 2016 14:28:04 +0100 In-Reply-To: <20161215125139.GC6336@aepfle.de> (Olaf Hering's message of "Thu, 15 Dec 2016 13:51:39 +0100") Message-ID: <87bmwd490b.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 15 Dec 2016 13:28:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1216 Lines: 31 Olaf Hering writes: > On Thu, Dec 15, Vitaly Kuznetsov wrote: > >> We actually need to read the reply and empty the message slot to make >> unload happen. And reading on a different CPU may not work, see: >> >> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html > > Does the following sentences mean the vmbus_signal_eom in > vmbus_wait_for_unload is a noop because the wrmsrl() is expected to > happen on the other cpu instead of the current cpu? > > ... > - When we read the message we need to clear the slot and signal the fact > to the hypervisor. In case there are more messages to this CPU pending > the hypervisor will deliver the next message. The signaling is done by > writing to an MSR so this can only be done on the appropriate CPU. > ... > -> K. Y., but these words were written before I implemented vmbus_wait_for_unload(), to me they just explain how we read messages. 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). -- Vitaly