From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynw7t-0007LH-Ol for qemu-devel@nongnu.org; Thu, 30 Apr 2015 17:36:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynw7q-0005qf-Hc for qemu-devel@nongnu.org; Thu, 30 Apr 2015 17:36:09 -0400 Received: from e17.ny.us.ibm.com ([129.33.205.207]:55171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynw7q-0005qW-DY for qemu-devel@nongnu.org; Thu, 30 Apr 2015 17:36:06 -0400 Received: from /spool/local by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 30 Apr 2015 17:36:05 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <20150430210449.11253.78857@loki> References: <1429684100-13354-1-git-send-email-mdroth@linux.vnet.ibm.com> <20150430041304.GA17449@voom.redhat.com> <20150430210449.11253.78857@loki> Message-ID: <20150430213559.11253.26756@loki> Date: Thu, 30 Apr 2015 16:35:59 -0500 Subject: Re: [Qemu-devel] [PATCH v8 00/16] spapr: add support for pci hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: aik@ozlabs.ru, qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, bharata.rao@gmail.com, nfont@linux.vnet.ibm.com Quoting Michael Roth (2015-04-30 16:04:49) > Quoting David Gibson (2015-04-29 23:13:04) > > On Wed, Apr 22, 2015 at 01:28:04AM -0500, Michael Roth wrote: > > > These patches are based on spapr-next, and can also be obtained > > > from: > > = > > Thanks Michael. > > = > > I've made a few small conflict fixes and merged this into spapr-next. > = > Great, thanks! > = > > = > > Could you please: > > = > > a) Pull the new spapr-next and test that your code still works > = > I've run it through all my basic testing and things look good. I did > need one change though regarding the 2.4 machine type intro though: > = > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index a8116d0..8fbcaf5 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1919,6 +1919,7 @@ static void spapr_machine_register_types(void) > type_register_static(&spapr_machine_2_1_info); > type_register_static(&spapr_machine_2_2_info); > type_register_static(&spapr_machine_2_3_info); > + type_register_static(&spapr_machine_2_4_info); > } > = > type_init(spapr_machine_register_types) > = > Just needs to get squashed into "pseries: Add pseries-2.4 machine type" > I'd imagine. > = > > = > > b) Send me some minimal instructions for doing a basic test of PCI > > hotplug. I have some spapr cleanups in mind, and I'd like to be > > able to check for myself that I at least haven't broken things > > totally. > = > For all the following tests, the following guest distros (assuming they're > updated) should support the hotplug event and will do the whole device > bring-up/tear-down in response to hotplug/unplug: Fedora 21+, RHEL 6.6+, = > rhel 7.1+, sles12+, ubuntu 14.04+. > = > For quick testing just booting to SLOF you can do a reboot after > device_add/device_del to get the device picked up by SLOF PCI enumeration, > or finalized by QEMU's reset hooks, respectively. This won't exercise any > RTAS calls or actual device functionality, but should touch most of the > hotplug-related code. > = > =3D BASIC TEST > = > # start guest with an extra PHB to cover hotplug across multiple PHBs > = > qemu ... -device spapr-pci-host-bridge,index=3D1,phb1 > = > # from QEMU HMP monitor > = > netdev_add user,id=3Dhpnet0.0 > device_add virtio-net-pci,id=3Dhp0.0,netdev=3Dhpnet0.0 #PHB 0 > netdev_add user,id=3Dhpnet1.0 > device_add virtio-net-pci,id=3Dhp1.0,netdev=3Dhpnet1.0,bus=3Dphb1.0 #PHB= 1 > = > that interfaces can be brought online and lease IPs> > monitor command> > = > device_del hp0.0 > netdev_del hpnet0.0 > device_del hp1.0 > netdev_del hpnet1.0 > = > > are removed from output of 'info pci' monitor command> > = > =3D MULTIFUNCTION HOTPLUG TEST > = > #start guest as above > = > netdev_add user,id=3Dhpnet1.0.0 > device_add virtio-net-pci,id=3Dhp1.0.0,netdev=3Dhpnet1.0.0,bus=3Dphb1.0,\ > addr=3D0x0.0,multifunction=3Don > netdev_add user,id=3Dhpnet1.0.1 > device_add virtio-net-pci,id=3Dhp1.0.1,netdev=3Dhpnet1.0.1,bus=3Dphb1.0,\ > addr=3D0x0.1,multifunction=3Don > = > device> > = > device_del hp1.0.0 > netdev_del hpnet1.0.0 > device_del hp1.0.1 > netdev_del hpnet1.0.1 Actually this should probably be: device_del hp1.0.1 netdev_del hpnet1.0.1 device_del hp1.0.0 netdev_del hpnet1.0.0 From=20what I recall multifunction devices are expected to have a 0 function present when attached, and behavior is undefined otherwise. > = > > = > > = > > -- = > > David Gibson | I'll have my music baroque, and my co= de > > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _ot= her_ > > | _way_ _around_! > > http://www.ozlabs.org/~dgibson