Re: [Qemu-ppc] [PATCHv2 0/8] spapr: DRC cleanups (part VI)

[David Gibson]

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:
> 
> address@hidden:~$ 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
> address@hidden:~$ (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?

> I am not aware of anyone (e.g. Libvirt) using device_add at that point so
> it's not
> urgent to make this work AFAIC. I was just curious of why it
> doesn't.

Hm, I thought libvirt did use device_add here in at least some
circumstances.

I've gone ahead and sent a pull req with the changes, since AFAICT his
is not a regression, so the DRC cleanups still improve matters
overall.

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

signature.asc
Description: PGP signature