From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6E3EAC761A6 for ; Tue, 4 Apr 2023 14:11:56 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjhO2-0003K4-Of; Tue, 04 Apr 2023 10:11:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pjhO0-0003EM-8m for qemu-devel@nongnu.org; Tue, 04 Apr 2023 10:11:48 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pjhNy-0001aT-Ft for qemu-devel@nongnu.org; Tue, 04 Apr 2023 10:11:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680617505; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FEdPry9eYiISaWwLf8AG+PW56ohb43cLgTcCiFeKSEI=; b=LlohujpuxcWdBoCoMCl+5JPohQy2amTDA0FWrxaDD1ST3YVgH3OhqzCVT5de2uF3c8WwI1 5pglQdWe8NJjnWjbxhr+R8CiCpxNrWX+C+XT6iGjpPWkBgqOCy8ImwMHlfJCldOCanjFEW ytdjS3tPeLS5n0m2/jegTl86n/zIisg= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-rbq_DV0_MFCt7K-EXbHpSQ-1; Tue, 04 Apr 2023 10:11:43 -0400 X-MC-Unique: rbq_DV0_MFCt7K-EXbHpSQ-1 Received: by mail-ed1-f70.google.com with SMTP id c11-20020a509f8b000000b00501e2facf47so46490312edf.16 for ; Tue, 04 Apr 2023 07:11:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680617502; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FEdPry9eYiISaWwLf8AG+PW56ohb43cLgTcCiFeKSEI=; b=C8HjDRRA7yRM0PAUGfXRBgWxwZ919F+y0RrCmTzGxlerm4o46qQXfgu6lCDjGZD+Cf hL3VocOnTK3NHd6S5kpzvcHEhhh4xbih6rbLedvAsH60EbR3vKVH44BDgWjDZ0JL6hiO x+2Y+pVxpodRaKUBwFMcnYO5f5LE95YI30g3O/oxwl6C5VJUHSaR+NW9wCS4BySIwvu6 NICeGI+/c4PWZY/a7hh0nFGjMzLtDH8LWF3QVsc3VpOYMqgHAhJM2ijeFSE6OzFRJqGJ 3xs/qwTrg604b6hO46GK0tgdsT7u+pM5Kb82Ykpi2XImD9ZWtEZQsAjVPTk5jRoTKCJ9 HXmw== X-Gm-Message-State: AAQBX9dYuqcGyrB3mB8S7om6GpfvP+kaWD2ZM/5/W4mQq2tGZh+DOR81 756/f4TW6thG5YESwc5Jy8PxiUFS88GlbO5YjQZdKo1OwoeLJCBoZnbYAqJW8vJrBHd0Y4OPwGK AxdutT0pauNyXqfht1LGT6Tfp9WM3oF8= X-Received: by 2002:a17:906:9615:b0:935:3085:303b with SMTP id s21-20020a170906961500b009353085303bmr1292798ejx.15.1680617502671; Tue, 04 Apr 2023 07:11:42 -0700 (PDT) X-Google-Smtp-Source: AKy350ZmNY0nONEMu3p3/qVfIKizSlcvHIHMMO+ts6y5N5MWuSA4iPes0hRMLSf3v3mH9BP1qTZjCtMvnAO5FQzhPPA= X-Received: by 2002:a17:906:9615:b0:935:3085:303b with SMTP id s21-20020a170906961500b009353085303bmr1292784ejx.15.1680617502462; Tue, 04 Apr 2023 07:11:42 -0700 (PDT) MIME-Version: 1.0 References: <20230403161618.1344414-1-imammedo@redhat.com> In-Reply-To: <20230403161618.1344414-1-imammedo@redhat.com> From: Ani Sinha Date: Tue, 4 Apr 2023 19:41:31 +0530 Message-ID: Subject: Re: [PATCH] acpi: pcihp: make pending delete expire in 5sec To: Igor Mammedov Cc: qemu-devel@nongnu.org, mst@redhat.com, jusual@redhat.com, kraxel@redhat.com Content-Type: multipart/alternative; boundary="0000000000003cebb105f88341ad" Received-SPF: pass client-ip=170.10.133.124; envelope-from=anisinha@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --0000000000003cebb105f88341ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 3, 2023 at 9:46=E2=80=AFPM Igor Mammedov = wrote: > with Q35 using ACPI PCI hotplug by default, user's request to unplug > device is ignored when it's issued before guest OS has been booted. > And any additional attempt to request device hot-unplug afterwards > results in following error: > > "Device XYZ is already in the process of unplug" > > arguably it can be considered as a regression introduced by [2], > before which it was possible to issue unplug request multiple > times. > > Allowing pending delete expire brings ACPI PCI hotplug on par > with native PCIe unplug behavior [1] which in its turn refers > back to ACPI PCI hotplug ability to repeat unplug requests. > > PS: > From ACPI point of view, unplug request sets PCI hotplug status > bit in GPE0 block. However depending on OSPM, status bits may > be retained (Windows) or cleared (Linux) during guest's ACPI > subsystem initialization, and as result Linux guest looses > plug/unplug event (no SCI generated) if plug/unplug has > happend before guest OS initialized GPE registers handling. > I couldn't find any restrictions wrt OPM ^^^^ When you churn out a v2, can you fix this typo? > clearing GPE status > bits ACPI spec. > Hence a fallback approach is to let user repeat unplug request > later at the time when guest OS has booted. > > 1) 18416c62e3 ("pcie: expire pending delete") > 2) > Fixes: cce8944cc9ef ("qdev-monitor: Forbid repeated device_del") > Signed-off-by: Igor Mammedov > --- > CC: mst@redhat.com > CC: anisinha@redhat.com > CC: jusual@redhat.com > CC: kraxel@redhat.com > --- > hw/acpi/pcihp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c > index dcfb779a7a..cd4f9fee0a 100644 > --- a/hw/acpi/pcihp.c > +++ b/hw/acpi/pcihp.c > @@ -357,6 +357,8 @@ void > acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, > * acpi_pcihp_eject_slot() when the operation is completed. > */ > pdev->qdev.pending_deleted_event =3D true; > + pdev->qdev.pending_deleted_expires_ms =3D > + qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 5000; /* 5 secs */ > s->acpi_pcihp_pci_status[bsel].down |=3D (1U << slot); > acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_STATUS); > } > -- > 2.39.1 > > --0000000000003cebb105f88341ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 3, 2023 at 9:46=E2=80=AFP= M Igor Mammedov <imammedo@redhat.= com> wrote:
with Q35 using ACPI PCI hotplug by default, user's request to unplug=
device is ignored when it's issued before guest OS has been booted.
And any additional attempt to request device hot-unplug afterwards
results in following error:

=C2=A0 "Device XYZ is already in the process of unplug"

arguably it can be considered as a regression introduced by [2],
before which it was possible to issue unplug request multiple
times.

Allowing pending delete expire brings ACPI PCI hotplug on par
with native PCIe unplug behavior [1] which in its turn refers
back to ACPI PCI hotplug ability to repeat unplug requests.

PS:
>From ACPI point of view, unplug request sets PCI hotplug status
bit in GPE0 block. However depending on OSPM, status bits may
be retained (Windows) or cleared (Linux) during guest's ACPI
subsystem initialization, and as result Linux guest looses
plug/unplug event (no SCI generated) if plug/unplug has
happend before guest OS initialized GPE registers handling.
I couldn't find any restrictions wrt OPM
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^
When you churn = out a v2, can you fix this typo?
=C2=A0
clearing GPE status
bits ACPI spec.
Hence a fallback approach is to let user repeat unplug request
later at the time when guest OS has booted.

1) 18416c62e3 ("pcie: expire pending delete")
2)
Fixes: cce8944cc9ef ("qdev-monitor: Forbid repeated device_del")<= br> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
CC: mst@redhat.com<= br> CC: anisinha@redha= t.com
CC: jusual@redhat.co= m
CC: kraxel@redhat.co= m
---
=C2=A0hw/acpi/pcihp.c | 2 ++
=C2=A01 file changed, 2 insertions(+)

diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index dcfb779a7a..cd4f9fee0a 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -357,6 +357,8 @@ void acpi_pcihp_device_unplug_request_cb(HotplugHandler= *hotplug_dev,
=C2=A0 =C2=A0 =C2=A0 * acpi_pcihp_eject_slot() when the operation is comple= ted.
=C2=A0 =C2=A0 =C2=A0 */
=C2=A0 =C2=A0 =C2=A0pdev->qdev.pending_deleted_event =3D true;
+=C2=A0 =C2=A0 pdev->qdev.pending_deleted_expires_ms =3D
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 5000; = /* 5 secs */
=C2=A0 =C2=A0 =C2=A0s->acpi_pcihp_pci_status[bsel].down |=3D (1U <<= ; slot);
=C2=A0 =C2=A0 =C2=A0acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_S= TATUS);
=C2=A0}
--
2.39.1

--0000000000003cebb105f88341ad--