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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 043E4C433E0 for ; Wed, 20 May 2020 11:07:02 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C2591207C4 for ; Wed, 20 May 2020 11:07:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KIbvu1u6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2591207C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:44438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbMYu-0001Hd-VP for qemu-devel@archiver.kernel.org; Wed, 20 May 2020 07:07:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbMY4-0000Fy-Jf for qemu-devel@nongnu.org; Wed, 20 May 2020 07:06:08 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:37691 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1jbMY3-0007yq-1y for qemu-devel@nongnu.org; Wed, 20 May 2020 07:06:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589972765; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LO0/JMzOjyKZ+Gjq/JmVo8AIKXBtPo+aZfCixGGGJ9A=; b=KIbvu1u6sOyLl5orY1RwXYsbE80QpfWIPJWPC3PNWYKpMp8ioEHzc5xBWnI+NjpyNfgNkQ u7ZdkS6nH1pyjroCfiJMV5LVWw6LqM8Xx/zwN7LEKVZ7Sj2xY/KPQfeesFTizPo41ab+yd Xc/JYycpn8gTA0gYLIhE9I8DWsL1E3g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-274-n-rmh2akN1iB4tEW_1edBw-1; Wed, 20 May 2020 07:06:00 -0400 X-MC-Unique: n-rmh2akN1iB4tEW_1edBw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 21E2618A0721; Wed, 20 May 2020 11:05:59 +0000 (UTC) Received: from nas.mammed.net (unknown [10.40.193.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9BAAC82A35; Wed, 20 May 2020 11:05:50 +0000 (UTC) Date: Wed, 20 May 2020 13:05:47 +0200 From: Igor Mammedow To: "Michael S. Tsirkin" Subject: Re: [PATCH V2] Add a new PIIX option to control PCI hot unplugging of devices on non-root buses Message-ID: <20200520130547.7ac568b8@nas.mammed.net> In-Reply-To: <20200520060645-mutt-send-email-mst@kernel.org> References: <1588069012-211196-1-git-send-email-ani.sinha@nutanix.com> <20200511205352.05ff541a@redhat.com> <9941B800-BBEF-4DF8-BEE0-EC39D2A20D98@nutanix.com> <20200513214312.0dfa4752@redhat.com> <7FF83CE8-F25A-4458-80A7-EAA6296EF175@nutanix.com> <20200520114354.1982cb63@nas.mammed.net> <20200520054714-mutt-send-email-mst@kernel.org> <20200520115626.6a2a2355@nas.mammed.net> <20200520060645-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=205.139.110.61; envelope-from=imammedo@redhat.com; helo=us-smtp-delivery-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/20 02:22:41 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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: Ani Sinha , Eduardo Habkost , Julia Suvorova , "qemu-devel@nongnu.org" , Aleksandar Markovic , Ani Sinha , Paolo Bonzini , Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= , Aurelien Jarno , Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 20 May 2020 06:28:37 -0400 "Michael S. Tsirkin" wrote: > On Wed, May 20, 2020 at 11:56:26AM +0200, Igor Mammedow wrote: > > On Wed, 20 May 2020 05:47:53 -0400 > > "Michael S. Tsirkin" wrote: > > =20 > > > On Wed, May 20, 2020 at 11:43:54AM +0200, Igor Mammedow wrote: =20 > > > > On Fri, 15 May 2020 12:13:53 +0000 > > > > Ani Sinha wrote: > > > > =20 > > > > > > On May 14, 2020, at 1:13 AM, Igor Mammedov > > > > > > wrote: =20 > > > > > >>=20 > > > > > >> =20 > > > > > >>> Will following hack work for you? > > > > > >>> possible permutations > > > > > >>> 1) ACPI hotplug everywhere > > > > > >>> -global PIIX4_PM.acpi-pci-hotplug=3Don -global > > > > > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=3Don -device > > > > > >>> pci-bridge,chassis_nr=3D1,shpc=3Ddoesnt_matter -device > > > > > >>> e1000,bus=3Dpci.1,addr=3D01,id=3Dnetdev1=20 > > > > > >>>=20 > > > > > >>> 2) No hotplug at all > > > > > >>> -global PIIX4_PM.acpi-pci-hotplug=3Doff -global > > > > > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=3Don -device > > > > > >>> pci-bridge,chassis_nr=3D1,shpc=3Doff -device > > > > > >>> e1000,bus=3Dpci.1,addr=3D01,id=3Dnetdev1 > > > > > >>>=20 > > > > > >>> -global PIIX4_PM.acpi-pci-hotplug=3Doff -global > > > > > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=3Doff -device > > > > > >>> pci-bridge,chassis_nr=3D1,shpc=3Ddoesnt_matter -device > > > > > >>> e1000,bus=3Dpci.1,addr=3D01,id=3Dnetdev1 =20 > > > > > >>=20 > > > > > >> Given that my patch is not acceptable, I=E2=80=99d prefer the > > > > > >> following in the order of preference: > > > > > >>=20 > > > > > >> (a) Have an option to disable hot ejection of PCI-PCI > > > > > >> bridge so that Windows does not even show this HW in the > > > > > >> =E2=80=9Csafely remove HW=E2=80=9D option. If we can do this t= hen from OS > > > > > >> perspective the GUI options will be same as what is > > > > > >> available with PCIE/q35 - none of the devices will be hot > > > > > >> ejectable if the hot plug option is turned off from the > > > > > >> PCIE slots where devices are plugged into. I looked at the > > > > > >> code. It seems to manipulate ACPI tables of the empty > > > > > >> slots of the root bus where no devices are attached (see > > > > > >> comment "/* add hotplug slots for non present devices */ > > > > > >> =E2=80=9C). For cold plugged bridges, it recurses down to scan= the > > > > > >> slots of the bridge. Is it possible to disable hot plug > > > > > >> for the slot to which the bridge is attached? =20 > > > > > >=20 > > > > > > I don't think it's possible to have per slot hotplug on > > > > > > conventional PCI hardware. it's per bridge property. =20 > > > > >=20 > > > > > We add the AMLs per empty slot though. When the pic bridge is > > > > > attached, we do nothing, just recurse into the bridge slots. > > > > > That is what I was asking, if it was possible to just disable > > > > > the AMLs or use some tricks to say that this particular slot > > > > > is not hotpluggable. I am not sure why Windows is trying to > > > > > eject the PCI bridge and failing. Maybe something related to > > > > > this comment? > > > > >=20 > > > > >=20 > > > > > /* When hotplug for bridges is enabled, bridges are > > > > > =20 > > > > > * described in ACPI separately (see > > > > > build_pci_bus_end).=20 > > > > > * In this case they aren't themselves hot-pluggable. > > > > > =20 > > > > > * Hotplugged bridges *are* hot-pluggable. > > > > > */ =20 > > > >=20 > > > > thinking some more on this topic, it seems that with ACPI > > > > hotplug we already have implicit non-hotpluggble slot (slot > > > > with bridge) while the rest are staying hotpluggable. > > > >=20 > > > > So my question is: if it's acceptable to add > > > > 'PCIDevice::hotpluggable" property to all PCI devices so that > > > > user / libvirt could set it to false in case they do not want > > > > coldplugged device be considered as hotpluggable? (this way > > > > other devices could be treated the same way as bridges) > > > >=20 > > > > [...] =20 > > >=20 > > >=20 > > > I think Julia already posted a patch adding this to downstream > > > pcie bridges. Adding this to pci slots sounds like a reasonable > > > thing. =20 > > Question was more about external interface, were we do not have > > ports as separate devices with conventional PCI. The only knob we > > have is a a PCI device, where we have a property to turn on/off > > hotplug. ex: -device e1000,hotpluggable=3Doff > > and if libvirt would be able to use it =20 >=20 > It would make sense but is it practical to add the capability is added > in a generic way to all bridges and hosts? > If not how do users probe for presence of the capability? it probably won't work with native SHPC hotplug (which looks to be incomplete in QEMU anyway), but it should work with ACPI and per port PCIE hotplugs. In case of SHPC, we probably should be able to cleanly error out with 'unsupported' reason if "hotpluggable" conflicts with bridge policy.