| Message ID | 20150430210449.11253.78857@loki |
|---|---|
| State | New |
| Headers | show |
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. > > = BASIC TEST > > # start guest with an extra PHB to cover hotplug across multiple PHBs > > qemu ... -device spapr-pci-host-bridge,index=1,phb1 > > # from QEMU HMP monitor > > netdev_add user,id=hpnet0.0 > device_add virtio-net-pci,id=hp0.0,netdev=hpnet0.0 #PHB 0 > netdev_add user,id=hpnet1.0 > device_add virtio-net-pci,id=hp1.0,netdev=hpnet1.0,bus=phb1.0 #PHB 1 > > <if running supported distro, verify devices show up in lspci, and > that interfaces can be brought online and lease IPs> > <if just booting to SLOF, verify devices are preset via 'info pci' > monitor command> > > device_del hp0.0 > netdev_del hpnet0.0 > device_del hp1.0 > netdev_del hpnet1.0 > > <if running supported distro, verify devices are removed from lspci> > <if just booting to SLOF, issue system_reset and verify devices > are removed from output of 'info pci' monitor command> > > = MULTIFUNCTION HOTPLUG TEST > > #start guest as above > > netdev_add user,id=hpnet1.0.0 > device_add virtio-net-pci,id=hp1.0.0,netdev=hpnet1.0.0,bus=phb1.0,\ > addr=0x0.0,multifunction=on > netdev_add user,id=hpnet1.0.1 > device_add virtio-net-pci,id=hp1.0.1,netdev=hpnet1.0.1,bus=phb1.0,\ > addr=0x0.1,multifunction=on > > <verify each function as above, and that they're functions of the same > 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 what I recall multifunction devices are expected to have a 0 function present when attached, and behavior is undefined otherwise. > > <verify each function as above> > > > > > -- > > David Gibson | I'll have my music baroque, and my code > > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > > | _way_ _around_! > > http://www.ozlabs.org/~dgibson
On Thu, Apr 30, 2015 at 04:04:49PM -0500, Michael Roth wrote: > 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. Oops, that's an embarrasing omission. Fixed now.
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)