From nobody Mon Feb 9 21:32:41 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=yandex-team.ru ARC-Seal: i=1; a=rsa-sha256; t=1604295568; cv=none; d=zohomail.com; s=zohoarc; b=We6+SGZINw268IZe4edhcIq5vGSKe16dnogUc4NpLa3FAJr6NKx0R/yRKKs5z1KcPnZwqiAhX+YwEOVw4aPWVJCZkuhzzoK0GSt/YMXNiHxUqkXJ/FZc1eLDppgyOy/Zd541AnJMWzrstGaiX4MHY8Ib7gJsPxdwvsTpuvIPpgA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1604295568; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=w1p+M4bytOYcc9eybEp8vVRX5dHM418kcy618LYUs3Q=; b=fe3pVRX/frJqEAW/aGoKcGNuBNpS6QBELTjdJnUGLknPdRd31p7T2/Og+UX6JTrgdZYzw4Zp1qyyzKCFaEDLE7xFcRxa3Qxqv4qSaCplVF0Xgji0qQlj8loXQMTTPYr2865skxjzyRUYr5NZVrBZaPH3SzZruNVMS1PddiUjM9A= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1604295568977959.2235199538452; Sun, 1 Nov 2020 21:39:28 -0800 (PST) Received: from localhost ([::1]:53456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZSYw-0006rt-3t for importer@patchew.org; Mon, 02 Nov 2020 00:39:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZSXc-0006PR-9o for qemu-devel@nongnu.org; Mon, 02 Nov 2020 00:38:04 -0500 Received: from forwardcorp1j.mail.yandex.net ([5.45.199.163]:38078) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZSXX-0007aA-Hq for qemu-devel@nongnu.org; Mon, 02 Nov 2020 00:38:01 -0500 Received: from vla1-fdfb804fb3f3.qloud-c.yandex.net (vla1-fdfb804fb3f3.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3199:0:640:fdfb:804f]) by forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id 4D9902E14A5; Mon, 2 Nov 2020 08:37:51 +0300 (MSK) Received: from vla5-58875c36c028.qloud-c.yandex.net (vla5-58875c36c028.qloud-c.yandex.net [2a02:6b8:c18:340b:0:640:5887:5c36]) by vla1-fdfb804fb3f3.qloud-c.yandex.net (mxbackcorp/Yandex) with ESMTP id eYdk0TlvHf-bpxmXQJt; Mon, 02 Nov 2020 08:37:51 +0300 Received: from dynamic-vpn.dhcp.yndx.net (dynamic-vpn.dhcp.yndx.net [2a02:6b8:b081:114::1:2]) by vla5-58875c36c028.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id xsYJakoIsR-boneZij0; Mon, 02 Nov 2020 08:37:51 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1604295471; bh=w1p+M4bytOYcc9eybEp8vVRX5dHM418kcy618LYUs3Q=; h=Message-Id:Date:Subject:To:From:Cc; b=whbEFPTj1ufR4hIPqVqs8NvBuLpZ/M+XnOWHs/0EGh7Mf87img4nF84L8SJOPLSa5 nV6YJNDTeh3WcJGuYDiUOGFRKPHNUS5TrnDqBkPzxK2GgQY+4fKWZmSNKm7p3eMFJs wKmPCg4bcl3c215UIgj0OjS5epmJQbHTYHy9RC58= Authentication-Results: vla1-fdfb804fb3f3.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Roman Kagan To: qemu-devel@nongnu.org Subject: [PATCH] pci/shpc: don't push attention button when ejecting powered-off device Date: Mon, 2 Nov 2020 08:37:50 +0300 Message-Id: <20201102053750.2281818-1-rvkagan@yandex-team.ru> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=5.45.199.163; envelope-from=rvkagan@yandex-team.ru; helo=forwardcorp1j.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/02 00:37:51 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" When the slot is in steady powered-off state and the device is being removed, there's no need to press the attention button. Nor is it mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0. Moreover it confuses the guest, Linux in particular, as it assumes that the attention button pressed in this state indicates that the device has been inserted and will need to be powered on. Therefore it transitions the slot into BLINKING_ON state for 5 seconds, and discovers at the end that no device is actually inserted: ... unplug request [12685.451329] shpchp 0000:01:00.0: Button pressed on Slot(2) [12685.455478] shpchp 0000:01:00.0: PCI slot #2 - powering off due to butto= n press ... in 5 seconds OS powers off the slot, QEMU ejects the device [12690.632282] shpchp 0000:01:00.0: Latch open on Slot(2) ... excessive button press in steady powered-off state [12690.634267] shpchp 0000:01:00.0: Button pressed on Slot(2) [12690.636256] shpchp 0000:01:00.0: Card not present on Slot(2) ... the last button press spawns powering on the slot [12690.638909] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button= press ... in 5 more seconds attempt to power on discovers empty slot [12695.735986] shpchp 0000:01:00.0: No adapter on slot(2) Worse, if the real device insertion happens within 5 seconds from the apparent completion of the previous device removal (signaled via DEVICE_DELETED event), the new button press will be interpreted as the cancellation of that misguided powering on: [13448.965295] shpchp 0000:01:00.0: Button pressed on Slot(2) [13448.969430] shpchp 0000:01:00.0: PCI slot #2 - powering off due to butto= n press [13454.025107] shpchp 0000:01:00.0: Latch open on Slot(2) [13454.027101] shpchp 0000:01:00.0: Button pressed on Slot(2) [13454.029165] shpchp 0000:01:00.0: Card not present on Slot(2) ... the excessive button press spawns powering on the slot ... device has already been ejected by QEMU [13454.031949] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button= press ... new device is inserted in the slot [13456.861545] shpchp 0000:01:00.0: Latch close on Slot(2) ... valid button press arrives before 5 s since the wrong one [13456.864894] shpchp 0000:01:00.0: Button pressed on Slot(2) [13456.869211] shpchp 0000:01:00.0: Card present on Slot(2) ... the valid button press is counted as cancellation of the wrong one [13456.873173] shpchp 0000:01:00.0: Button cancel on Slot(2) [13456.877101] shpchp 0000:01:00.0: PCI slot #2 - action canceled due to bu= tton press As a result, the newly inserted device isn't brought up by the guest. Avoid this situation by not pushing the attention button when the device in the slot is in powered-off state and is being ejected. FWIW pcie implementation doesn't suffer from this problem. Signed-off-by: Roman Kagan --- hw/pci/shpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c index b00dce629c..837159c5bd 100644 --- a/hw/pci/shpc.c +++ b/hw/pci/shpc.c @@ -300,7 +300,6 @@ static void shpc_slot_command(SHPCDevice *shpc, uint8_t= target, shpc_set_status(shpc, slot, SHPC_SLOT_STATUS_PRSNT_EMPTY, SHPC_SLOT_STATUS_PRSNT_MASK); shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |=3D - SHPC_SLOT_EVENT_BUTTON | SHPC_SLOT_EVENT_MRL | SHPC_SLOT_EVENT_PRESENCE; } @@ -566,7 +565,6 @@ void shpc_device_unplug_request_cb(HotplugHandler *hotp= lug_dev, return; } =20 - shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |=3D SHPC_SLOT_EVENT_BUTTON; state =3D shpc_get_status(shpc, slot, SHPC_SLOT_STATE_MASK); led =3D shpc_get_status(shpc, slot, SHPC_SLOT_PWR_LED_MASK); if (state =3D=3D SHPC_STATE_DISABLED && led =3D=3D SHPC_LED_OFF) { @@ -577,6 +575,8 @@ void shpc_device_unplug_request_cb(HotplugHandler *hotp= lug_dev, shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |=3D SHPC_SLOT_EVENT_MRL | SHPC_SLOT_EVENT_PRESENCE; + } else { + shpc->config[SHPC_SLOT_EVENT_LATCH(slot)] |=3D SHPC_SLOT_EVENT_BUT= TON; } shpc_set_status(shpc, slot, 0, SHPC_SLOT_STATUS_66); shpc_interrupt_update(pci_hotplug_dev); --=20 2.28.0