From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9FA0-0000Gd-R3 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 12:47:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9F9y-0006sn-80 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 12:47:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44044) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9F9x-0006qj-Uo for qemu-devel@nongnu.org; Tue, 22 Nov 2016 12:47:10 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B68C34F65C for ; Tue, 22 Nov 2016 17:47:08 +0000 (UTC) Date: Tue, 22 Nov 2016 19:47:07 +0200 From: "Michael S. Tsirkin" Message-ID: <20161122194405-mutt-send-email-mst@kernel.org> References: <1478099802-14188-1-git-send-email-marcel@redhat.com> <20161103061711-mutt-send-email-mst@kernel.org> <8400224e-073e-eebc-bbb6-43bae96f3155@redhat.com> <20161103213514-mutt-send-email-mst@kernel.org> <20161116164442.wrwbs7cobkiclymp@kamzik.brq.redhat.com> <55156135-9617-906a-e65b-ce948dc22140@redhat.com> <20161118155201.uifhhouuidl2bsha@kamzik.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118155201.uifhhouuidl2bsha@kamzik.brq.redhat.com> Subject: Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: Marcel Apfelbaum , qemu-devel@nongnu.org, Gerd Hoffmann , Markus Armbruster , laine@redhat.com On Fri, Nov 18, 2016 at 04:52:01PM +0100, Andrew Jones wrote: > On Wed, Nov 16, 2016 at 07:05:25PM +0200, Marcel Apfelbaum wrote: > > On 11/16/2016 06:44 PM, Andrew Jones wrote: > > > On Sat, Nov 05, 2016 at 06:46:34PM +0200, Marcel Apfelbaum wrote: > > > > On 11/03/2016 09:40 PM, Michael S. Tsirkin wrote: > > > > > On Thu, Nov 03, 2016 at 01:05:44PM +0200, Marcel Apfelbaum wrote: > > > > > > On 11/03/2016 06:18 AM, Michael S. Tsirkin wrote: > > > > > > > On Wed, Nov 02, 2016 at 05:16:42PM +0200, Marcel Apfelbaum wrote: > > > > > > > > The shpc component is optional while ACPI hotplug is used > > > > > > > > for hot-plugging PCI devices into a PCI-PCI bridge. > > > > > > > > Disabling the shpc by default will make slot 0 usable at boot time > > > > > > > > > > > > Hi Michael > > > > > > > > > > > > > > > > > > > > at the cost of breaking all hotplug for all non-acpi users. > > > > > > > > > > > > > > > > > > > Do we have a non-acpi user that is able to use the shpc component as-is today? > > > > > > > > > > power and some arm systems I guess? > > > > > > > > > > > > > Adding Andrew , maybe he can give us an answer. > > > > > > Not really :-) My lack of PCI knowledge makes that difficult. I'd be happy > > > to help with an experiment though. Can you give me command line arguments, > > > qmp commands, etc. that I should use to try it out? I imagine I should > > > just boot an ARM guest using DT (instead of ACPI) and then attempt to > > > hotplug a PCI device. I'm not sure, however, what, if any, special > > > configuration I need in order to ensure I'm testing what you're > > > interested in. > > > > > > > Hi Drew, > > > > > > Just run QEMU with '-device pci-bridge,chassis_nr=1,id=bridge1 -monitor stdio' > > with an ARM guest using DT and wait until the guest finish booting. > > > > Then run at hmp: > > device_add virtio-net-pci,bus=bridge1,id=net2 > > > > Next run lspci in the guest to see the new device. > > Thanks for the instructions Marcel. Here's the results > > $QEMU -machine virt,accel=$ACCEL -cpu $CPU -nographic -m 4096 -smp 8 \ > -bios /usr/share/AAVMF/AAVMF_CODE.fd \ > -device pci-bridge,chassis_nr=1,id=bridge1 \ > -drive file=$FEDORA_IMG,if=none,id=dr0,format=qcow2 \ > -device virtio-blk-pci,bus=bridge1,addr=01,drive=dr0,id=disk0 \ > -netdev user,id=hostnet0 \ > -device virtio-net-pci,bus=bridge1,addr=02,netdev=hostnet0,id=net0 > > # lspci > 00:00.0 Host bridge: Red Hat, Inc. Device 0008 > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge > 01:01.0 SCSI storage controller: Red Hat, Inc Virtio block device > 01:02.0 Ethernet controller: Red Hat, Inc Virtio network device > > (qemu) device_add virtio-net-pci,bus=bridge1,id=net2 > Unsupported PCI slot 0 for standard hotplug controller. Valid slots are > between 1 and 31. > > (Tried again giving addr=03) > > (qemu) device_add virtio-net-pci,bus=bridge1,id=net2,addr=03 > > (Seemed to work, but...) > > # lspci > 00:00.0 Host bridge: Red Hat, Inc. Device 0008 > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge > 01:01.0 SCSI storage controller: Red Hat, Inc Virtio block device > 01:02.0 Ethernet controller: Red Hat, Inc Virtio network device > > (Doesn't show up in lscpi. So I guess it doesn't work) Yes - I just realized people seem to disable CONFIG_HOTPLUG_PCI_SHPC there. I don't know why really - want to try rebuilding the kernel and seeing if there's any change? > > > > > > BTW, will an ARM guest run 'fast' enough to be usable on a x86 machine? > > If yes, any pointers on how to create such a guest? > > You can run AArch64 guests on x86 machines. It's not super fast though... > Certainly I wouldn't want to create my guest image using TCG. So, assuming > you acquire an image somewhere (or create it on a real machine), then you > can use the above command line, just change > > ACCEL=kvm CPU=host to ACCEL=tcg CPU=cortex-a57 > > Thanks, > drew