Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753286AbdDJM24 (ORCPT ); Mon, 10 Apr 2017 08:28:56 -0400 Received: from smtp-fw-6001.amazon.com ([52.95.48.154]:36388 "EHLO smtp-fw-6001.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343AbdDJM2y (ORCPT ); Mon, 10 Apr 2017 08:28:54 -0400 X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="275748406" From: "Raslan, KarimAllah" To: David Vrabel , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" CC: Juergen Gross , Ross Lagerwall , "linux-pci@vger.kernel.org" , "x86@kernel.org" , "Paul Gortmaker" , Julien Grall , Vitaly Kuznetsov , "Ingo Molnar" , "Liguori, Anthony" , "H. Peter Anvin" , Bjorn Helgaas , "Boris Ostrovsky" , Thomas Gleixner , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device Thread-Topic: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device Thread-Index: AQHSGyls4HVqpf3okEu6AyaikaN8R6G/1ykA Date: Mon, 10 Apr 2017 12:28:38 +0000 Message-ID: <5E59C7DE-9640-4D97-A633-BFFDC4BF1352@amazon.de> References: <1472248536-2063-1-git-send-email-karahmed@amazon.de> <57EE7AB7.4020405@citrix.com> In-Reply-To: <57EE7AB7.4020405@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.165.143] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3ACT5kh018985 Content-Length: 2169 Lines: 48 Unfortunately, this commit is potentially a candidate for reverting. After a lengthy qualification I realized that there is a function called: "xen_strict_xenbus_quirk()" that is being called in the offending path that short-circuits the offending code! So at the moment any domU kernel with this commit will not boot on any Xen version < 4.0! So nobody with Xen < 4.0 was complaining not because nobody is using it but rather because there is a short-circuit in the code that avoids hitting the offending code in the first place! So the original assumption that the code is dead might no be 100% correct! So even though the code for INTx is broken for any Xen > 4.0, the right thing to do now is to actually fix the INTx properly and completely revert this commit (actually now also commit da72ff5bfcb0 needs to be reverted to cleanly revert this commit) to avoid any potential regression. David, Does this make sense to you? I will send a patch to fix INTx shortly as well. On 9/30/16, 4:46 PM, "David Vrabel" wrote: On 26/08/16 22:55, KarimAllah Ahmed wrote: > Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches > from old kernel") using the INTx interrupt from Xen PCI platform device for > event channel notification would just lockup the guest during bootup. > postcore_initcall now calls xs_reset_watches which will eventually try to read > a value from XenStore and will get stuck on read_reply at XenBus forever since > the platform driver is not probed yet and its INTx interrupt handler is not > registered yet. That means that the guest can not be notified at this moment of > any pending event channels and none of the per-event handlers will ever be > invoked (including the XenStore one) and the reply will never be picked up by > the kernel. Applied to for-linus-4.9, thanks. David Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B