All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Cc: lvivier@redhat.com, qemu-devel@nongnu.org,
	mdroth@linux.vnet.ibm.com, groug@kaod.org, qemu-ppc@nongnu.org,
	sjitindarsingh@gmail.com, bharata@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCHv2 0/8] spapr: DRC cleanups (part VI)
Date: Sat, 15 Jul 2017 12:42:46 +1000	[thread overview]
Message-ID: <20170715024246.GI17539@umbus.fritz.box> (raw)
In-Reply-To: <9308b227-ed59-caf0-eb41-608d37b8ed30@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

On Fri, Jul 14, 2017 at 10:50:06AM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 07/14/2017 03:53 AM, David Gibson wrote:
> > On Thu, Jul 13, 2017 at 07:13:23AM -0300, Daniel Henrique Barboza wrote:
> > > 
> > > On 07/12/2017 09:57 PM, David Gibson wrote:
> > > > On Wed, Jul 12, 2017 at 10:48:38AM -0300, Daniel Henrique Barboza wrote:
> > > > > The dreaded Libvirt hotplug-migrate-hotunplug scenario is working nicely.
> > > > Good to hear.
> > > > 
> > > > > device_add when the machine is in RUN_STATE_PRELAUNCH (-S) still doesn't
> > > > > work but it is expected - as discussed in "[RFC drcVI PATCH] spapr: reset
> > > > > DRCs
> > > > > on migration pre_load​", this scenario can't be fixed solely by this DRC
> > > > > cleanup.
> > > > Hmm.. what's the exact test case you're using here?  The prelaunch
> > > > case I tried _did_ work (queueing the event during prelaunch, then
> > > > completing the hotplug sequence once the guest had booted).
> > > This is the test case:
> > > 
> > > sudo ./qemu-system-ppc64 -name migrate_qemu -boot strict=on --enable-kvm
> > > -device nec-usb-xhci,id=usb,bus=pci.0,addr=0xf -device
> > > spapr-vscsi,id=scsi0,reg=0x2000 -smp 1,maxcpus=4,sockets=4,cores=1,threads=1
> > > --machine pseries,accel=kvm,usb=off,dump-guest-core=off -m
> > > 4G,slots=32,maxmem=32G -drive file=/home/danielhb/vm_imgs/ubuntu1704.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none
> > > -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> > > -nographic -S
> > > QEMU 2.9.50 monitor - type 'help' for more information
> > > (qemu)
> > > (qemu) device_add host-spapr-cpu-core,id=core1,core-id=1
> > > (qemu) cont
> > > 
> > > (...)
> > > 
> > > After OS boots:
> > > 
> > > danielhb@ubuntu1704:~$ lscpu
> > > Architecture:          ppc64le
> > > Byte Order:            Little Endian
> > > CPU(s):                1
> > > On-line CPU(s) list:   0
> > > Thread(s) per core:    1
> > > Core(s) per socket:    1
> > > Socket(s):             1
> > > NUMA node(s):          1
> > > Model:                 2.1 (pvr 004b 0201)
> > > Model name:            POWER8E (raw), altivec supported
> > > Hypervisor vendor:     horizontal
> > > Virtualization type:   full
> > > L1d cache:             64K
> > > L1i cache:             32K
> > > NUMA node0 CPU(s):     0
> > > danielhb@ubuntu1704:~$ (qemu)
> > > (qemu) info cpus
> > > * CPU #0: nip=0xc0000000000a3e0c thread_id=6134
> > >    CPU #1: nip=0x0000000000000000 (halted) thread_id=6163
> > > (qemu) info hotpluggable-cpus
> > > Hotpluggable CPUs:
> > >    type: "host-spapr-cpu-core"
> > >    vcpus_count: "1"
> > >    CPUInstance Properties:
> > >      core-id: "3"
> > >    type: "host-spapr-cpu-core"
> > >    vcpus_count: "1"
> > >    CPUInstance Properties:
> > >      core-id: "2"
> > >    type: "host-spapr-cpu-core"
> > >    vcpus_count: "1"
> > >    qom_path: "/machine/peripheral/core1"
> > >    CPUInstance Properties:
> > >      core-id: "1"
> > >    type: "host-spapr-cpu-core"
> > >    vcpus_count: "1"
> > >    qom_path: "/machine/unattached/device[0]"
> > >    CPUInstance Properties:
> > >      core-id: "0"
> > > (qemu)
> > Huh.  I tried basically the same thing, and I get the second cpu once
> > the OS is booted.  My first guess would be that the difference is in
> > the guest (mine is RHEL 7.3).  Have you double checked that rtas_errd
> > and drmgr are present in your guest?
> 
> Yeah the guest has drmgr and rtas_errd running. As you said, there might be
> something different in the guests that explains why yours work and mine
> doesn't.
> Coupling that with the fact that this is not a common usage, I believe we
> can leave it as a FYI/reminder if we need to revisit this issue in the
> future.

I concur.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-07-15  3:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12  5:53 [Qemu-devel] [PATCHv2 0/8] spapr: DRC cleanups (part VI) David Gibson
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 1/8] spapr: Treat devices added before inbound migration as coldplugged David Gibson
2017-07-12  8:41   ` Greg Kurz
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 2/8] spapr: Remove 'awaiting_allocation' DRC flag David Gibson
2017-07-12  9:38   ` Laurent Vivier
2017-07-12 10:00   ` Greg Kurz
2017-07-12 11:05     ` David Gibson
2017-07-12 11:27       ` Greg Kurz
2017-07-12 17:04         ` Greg Kurz
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 3/8] spapr: Simplify unplug path David Gibson
2017-07-12 10:04   ` Greg Kurz
2017-07-12 10:31     ` Greg Kurz
2017-07-13  0:30       ` David Gibson
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 4/8] spapr: Refactor spapr_drc_detach() David Gibson
2017-07-12 11:47   ` Greg Kurz
2017-07-13  0:53     ` David Gibson
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 5/8] spapr: Cleanups relating to DRC awaiting_release field David Gibson
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 6/8] spapr: Consolidate DRC state variables David Gibson
2017-07-12 17:36   ` [Qemu-devel] [Qemu-ppc] " Daniel Henrique Barboza
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 7/8] spapr: Remove sPAPRConfigureConnectorState sub-structure David Gibson
2017-07-12 17:40   ` [Qemu-devel] [Qemu-ppc] " Daniel Henrique Barboza
2017-07-12  5:53 ` [Qemu-devel] [PATCHv2 8/8] spapr: Implement DR-indicator for physical DRCs only David Gibson
2017-07-12 17:44   ` [Qemu-devel] [Qemu-ppc] " Daniel Henrique Barboza
2017-07-12 13:48 ` [Qemu-devel] [Qemu-ppc] [PATCHv2 0/8] spapr: DRC cleanups (part VI) Daniel Henrique Barboza
2017-07-13  0:57   ` David Gibson
2017-07-13 10:13     ` Daniel Henrique Barboza
2017-07-14  6:53       ` David Gibson
2017-07-14 13:50         ` Daniel Henrique Barboza
2017-07-15  2:42           ` David Gibson [this message]
2017-07-13  1:09 ` [Qemu-devel] " David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170715024246.GI17539@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=danielhb@linux.vnet.ibm.com \
    --cc=groug@kaod.org \
    --cc=lvivier@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=sjitindarsingh@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.