| Message ID | 56BDB484.6020303@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, Feb 12, 2016 at 11:31:32AM +0100, Laurent Vivier wrote: > > > On 12/02/2016 11:06, Andrew Jones wrote: > > On Thu, Feb 11, 2016 at 06:47:22PM +0100, Laurent Vivier wrote: > >> > >> > >> On 11/02/2016 18:22, Andrew Jones wrote: > >>> On Thu, Feb 11, 2016 at 05:44:00PM +0100, Laurent Vivier wrote: > >>>> > >>>> > >>>> On 11/02/2016 16:29, Andrew Jones wrote: > >>>>> On Thu, Feb 11, 2016 at 02:36:57PM +0100, Laurent Vivier wrote: > >>>> > >>>>>> > >>>>>> - On fedora 23 on PowerMac G5 (ppc64) kvm_pr, it doesn't work at all: > >>>>>> > >>>>>> lib/powerpc/setup.c:60: assert failed > >>>>>> 59 assert(freemem_start >= mem_start && freemem_start < mem_end); > >>>>>> > >>>>>> The values I have are: > >>>>>> freemem_start 434000 mem_start 8000000 mem_end 10000000 > >>>>> > >>>>> That's interesting. I might know what the problem is though. If > >>>>> the spapr machine divides memory up into multiple regions in some > >>>>> kvm use cases, then I'll need to look at all of regions to either a) > >>>>> choose the one I want to use, or b) map them all for use. On that > >>>>> machine, can you run > >>>>> > >>>>> $ /usr/libexec/qemu-kvm -machine pseries,accel=kvm -machine dumpdtb=dtb > >>>>> $ dtc -I dtb -O dts dtb | less > >>>>> > >>>>> and then check if there are multiple memory regions? > >>>> > >>>> No output... fc23 has qemu-2.4.1, so this commit is missing: > >>>> ad440b4 spapr: add dumpdtb support > >>>> > >>>> So I've recompiled master (PPC970MP is not as fast as POWER8...), and: > >>>> > >>>> memory@0000000010000000 { > >>>> ibm,associativity = <0x4 0x0 0x0 0x0 0x0>; > >>>> reg = <0x0 0x10000000 0x0 0x10000000>; > >>>> device_type = "memory"; > >>>> }; > >>>> > >>>> memory@0000000008000000 { > >>>> ibm,associativity = <0x4 0x0 0x0 0x0 0x0>; > >>>> reg = <0x0 0x8000000 0x0 0x8000000>; > >>>> device_type = "memory"; > >>>> }; > >>>> > >>>> memory@0000000000000000 { > >>>> ibm,associativity = <0x4 0x0 0x0 0x0 0x0>; > >>>> reg = <0x0 0x0 0x0 0x8000000>; > >>>> device_type = "memory"; > >>>> }; > >>> > >>> OK, I can fix memory region mapping for v3 pretty easily. > >>> > >>>> > >>>> But master doesn't have the "assert()", it hangs, and in kernel logs: > >>>> > >>>> [ 438.503410] kvmppc_handle_exit_pr: emulation at 700 failed (00000000) > >>>> [ 438.503412] Couldn't emulate instruction 0x00000000 (op 0 xop 0) > >>> > >>> That 700 is what I got when I tried compiling with gcc-5.2, before > >>> changing the toc alignment. I guess that just means "we've gone off > >>> in the weeds." Unfortunately I don't have any idea why this time, > >>> assuming we've got the toc patched kvm-unit-tests. Does everything > >>> run except the rtas-poweroff command? If you comment the call to it > >>> out of exit(), and then just use ^C to quit, does it seem happy? > >> > >> Yes, it seems happy: nothing is displayed in terminal nor in the kernel > >> logs. > > > > Thanks for the extra test. Just to be clear though, do you mean no > > errors are logged, but we still get the expected printf output? Or > > was nothing at all output (in which case we're badly broken)? > > > > If it's the former, then I guess I screwed up the rtas call somehow, > > most likely by the way I tried to prepare the rtas entry function > > pointer for jumping into the blob provided in the DT. > > I have nothing at all. It hangs. Damn. I'll need to get a machine where the problems reproduce to debug. > > The command I run is: > kvm-unit-tests]$ sudo ./powerpc/run powerpc/selftest.elf -smp 2 -m 256 > -append 'setup smp=2 mem=256' > qemu-system-ppc64 -machine pseries,accel=kvm -bios powerpc/boot_rom.bin > -display none -serial stdio -kernel powerpc/selftest.elf -smp 2 -m 256 > -append setup smp=2 mem=256 > ^C > qemu: terminating on signal 2 > > > The change I did: > > --- a/lib/powerpc/io.c > +++ b/lib/powerpc/io.c > @@ -32,6 +32,6 @@ void exit(int code) > // FIXME: change this print-exit/rtas-poweroff to chr_testdev_exit() > // Maybe by plugging chr-testdev into a spapr-vty. > printf("\nEXIT: STATUS=%d\n", ((code) << 1) | 1); > - rtas_power_off(); > + //rtas_power_off(); > halt(code); > } Yup, that's what I was hoping would make things "work", guess it doesn't. Thanks for all the testing. drew -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 12, 2016 at 11:57:51AM +0100, Andrew Jones wrote: > On Fri, Feb 12, 2016 at 11:31:32AM +0100, Laurent Vivier wrote: > > I have nothing at all. It hangs. > > Damn. I'll need to get a machine where the problems reproduce to debug. I got a machine, an lpar, so using kvm_pr. I immediately hit a problem. Hung, no output. I was hitting the assert you found earlier, due to assuming a single memory region. The lack of output and rtas-poweroff were due to 'sc 1' being broken on this machine. I can fix that by patching like SLOF does, see [*]. Although I'm not 100% sure how I want to approach it yet. There are enough things to fix now that I should probably spin another version before you bother retesting on the PowerMac. I'll pull something together soon. Thanks, drew [*] http://git.qemu-project.org/?p=SLOF.git;a=patch;h=dd53579ae82bed0654dd3e4b3052ef2cac58b5f4 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 12, 2016 at 02:44:20PM +0100, Andrew Jones wrote: > On Fri, Feb 12, 2016 at 11:57:51AM +0100, Andrew Jones wrote: > > On Fri, Feb 12, 2016 at 11:31:32AM +0100, Laurent Vivier wrote: > > > I have nothing at all. It hangs. > > > > Damn. I'll need to get a machine where the problems reproduce to debug. > > I got a machine, an lpar, so using kvm_pr. I immediately hit a problem. > Hung, no output. I was hitting the assert you found earlier, due to > assuming a single memory region. The lack of output and rtas-poweroff were > due to 'sc 1' being broken on this machine. I can fix that by patching > like SLOF does, see [*]. Although I'm not 100% sure how I want to approach > it yet. I'm guessing your test machine was a PowerVM LPAR rather than a KVM LPAR. If you can find a KVM LPAR (IBM host or RHEV host, doesn't matter) things should work better. KVM includes a hack for this situation: an sc 1 coming from guest usermode is redirected to the guest kernel, instead of immediately returning H_PRIVILEGE, which allows the L0 guest / L1 host's kvm_pr to handle it. > There are enough things to fix now that I should probably spin another > version before you bother retesting on the PowerMac. I'll pull something > together soon. > > Thanks, > drew > > [*] http://git.qemu-project.org/?p=SLOF.git;a=patch;h=dd53579ae82bed0654dd3e4b3052ef2cac58b5f4 >
--- a/lib/powerpc/io.c +++ b/lib/powerpc/io.c @@ -32,6 +32,6 @@ void exit(int code) // FIXME: change this print-exit/rtas-poweroff to chr_testdev_exit() // Maybe by plugging chr-testdev into a spapr-vty. printf("\nEXIT: STATUS=%d\n", ((code) << 1) | 1); - rtas_power_off(); + //rtas_power_off(); halt(code); }