[Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Hervé Poussineau]

Hi,

Following patch regresses Linux boot on PReP machine:

commit a2e71b28e832346409efc795ecd1f0a2bcb705a3
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Jun 21 23:48:46 2016 +0200

     ppc: Fix rfi/rfid/hrfi/... emulation

     This reworks emulation of the various "rfi" variants. I removed
     some masking bits that I couldn't make sense of, the only bit that
     I am aware we should mask here is POW, the CPU's MSR mask should
     take care of the rest.

     This also fixes some problems when running 32-bit userspace under
     a 64-bit kernel.

     This patch broke 32bit OpenBIOS when run under a 970 cpu. A fix was
     proposed here :

         https://www.coreboot.org/pipermail/openbios/2016-June/009452.html

     Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
     Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
     [clg: updated the commit log with the reference of the openbios fix ]
     Signed-off-by: Cédric Le Goater <clg@kaod.org>
     [dwg: Remove hunk which disabled rfi on 64-bit CPUS.  The change was
      correct, but we need to fix OpenBIOS before applying it]
     Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Test case:
- Download: http://www.juneau-lug.org/zImage.initrd.sandalfoot
- Run: qemu-system-ppc -M prep -kernel zImage.initrd.sandalfoot

Firmware starts, loads kernel, but seems to error out just after PS/2 detection.

Reverting the commit and fixing the conflict makes it work again, up to shell.

Hervé

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Mark Cave-Ayland]

On 24/08/16 19:39, Hervé Poussineau wrote:

> Hi,
> 
> Following patch regresses Linux boot on PReP machine:
> 
> commit a2e71b28e832346409efc795ecd1f0a2bcb705a3
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Tue Jun 21 23:48:46 2016 +0200
> 
>     ppc: Fix rfi/rfid/hrfi/... emulation
> 
>     This reworks emulation of the various "rfi" variants. I removed
>     some masking bits that I couldn't make sense of, the only bit that
>     I am aware we should mask here is POW, the CPU's MSR mask should
>     take care of the rest.
> 
>     This also fixes some problems when running 32-bit userspace under
>     a 64-bit kernel.
> 
>     This patch broke 32bit OpenBIOS when run under a 970 cpu. A fix was
>     proposed here :
> 
>         https://www.coreboot.org/pipermail/openbios/2016-June/009452.html
> 
>     Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>     [clg: updated the commit log with the reference of the openbios fix ]
>     Signed-off-by: Cédric Le Goater <clg@kaod.org>
>     [dwg: Remove hunk which disabled rfi on 64-bit CPUS.  The change was
>      correct, but we need to fix OpenBIOS before applying it]
>     Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Test case:
> - Download: http://www.juneau-lug.org/zImage.initrd.sandalfoot
> - Run: qemu-system-ppc -M prep -kernel zImage.initrd.sandalfoot
> 
> Firmware starts, loads kernel, but seems to error out just after PS/2
> detection.
> 
> Reverting the commit and fixing the conflict makes it work again, up to
> shell.

I can at least confirm that the v4 patch was applied to OpenBIOS for the
last update:
http://git.qemu.org/?p=openbios.git;a=commit;h=b747b6acc272f6ab839728193042455c9b36e26a.


ATB,

Mark.

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Benjamin Herrenschmidt]

On Wed, 2016-08-24 at 20:39 +0200, Hervé Poussineau wrote:
> Hi,
> 
> Following patch regresses Linux boot on PReP machine:

Where do I find the source for that kernel ?

Cheers,
Ben.

> commit a2e71b28e832346409efc795ecd1f0a2bcb705a3
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Tue Jun 21 23:48:46 2016 +0200
> 
>      ppc: Fix rfi/rfid/hrfi/... emulation
> 
>      This reworks emulation of the various "rfi" variants. I removed
>      some masking bits that I couldn't make sense of, the only bit
> that
>      I am aware we should mask here is POW, the CPU's MSR mask should
>      take care of the rest.
> 
>      This also fixes some problems when running 32-bit userspace
> under
>      a 64-bit kernel.
> 
>      This patch broke 32bit OpenBIOS when run under a 970 cpu. A fix
> was
>      proposed here :
> 
>          https://www.coreboot.org/pipermail/openbios/2016-June/009452
> .html
> 
>      Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>      Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>      [clg: updated the commit log with the reference of the openbios
> fix ]
>      Signed-off-by: Cédric Le Goater <clg@kaod.org>
>      [dwg: Remove hunk which disabled rfi on 64-bit CPUS.  The change
> was
>       correct, but we need to fix OpenBIOS before applying it]
>      Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Test case:
> - Download: http://www.juneau-lug.org/zImage.initrd.sandalfoot
> - Run: qemu-system-ppc -M prep -kernel zImage.initrd.sandalfoot
> 
> Firmware starts, loads kernel, but seems to error out just after PS/2
> detection.
> 
> Reverting the commit and fixing the conflict makes it work again, up
> to shell.
> 
> Hervé

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Benjamin Herrenschmidt]

On Wed, 2016-08-24 at 20:39 +0200, Hervé Poussineau wrote:
> Hi,
> 
> Following patch regresses Linux boot on PReP machine:
> 
> commit a2e71b28e832346409efc795ecd1f0a2bcb705a3
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Tue Jun 21 23:48:46 2016 +0200
> 
>      ppc: Fix rfi/rfid/hrfi/... emulation
> 
>      This reworks emulation of the various "rfi" variants. I removed
>      some masking bits that I couldn't make sense of, the only bit
> that

Interesting, the problem is only with 603, not 604. I think I might
have broken something with the 603 SW TLB loading stuff which is
a bit weird, I'll have a look. Thanks.

Cheers,
Ben.

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Benjamin Herrenschmidt]

On Thu, 2016-08-25 at 11:31 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2016-08-24 at 20:39 +0200, Hervé Poussineau wrote:
> > 
> > Hi,
> > 
> > Following patch regresses Linux boot on PReP machine:
> > 
> > commit a2e71b28e832346409efc795ecd1f0a2bcb705a3
> > Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date:   Tue Jun 21 23:48:46 2016 +0200
> > 
> >      ppc: Fix rfi/rfid/hrfi/... emulation
> > 
> >      This reworks emulation of the various "rfi" variants. I
> > removed
> >      some masking bits that I couldn't make sense of, the only bit
> > that
> 
> Interesting, the problem is only with 603, not 604. I think I might
> have broken something with the 603 SW TLB loading stuff which is
> a bit weird, I'll have a look. Thanks.

Actually it's trickier than that...

PReP seems to default to 602 ! Linux never supported the 602 so that's
really strange.

If I use 603 instead, I quickly hit a bad SPR, looks like we are trying
to hit the DABR which is ... odd. Probably getting into xmon but your
kernel is trying to get to the video rather than the serial port so I
can't see it.

I need that kernel source, we dropped PReP support from Linux ages
ago...

Cheers,
Ben.

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Benjamin Herrenschmidt]

On Thu, 2016-08-25 at 11:31 +1000, Benjamin Herrenschmidt wrote:
> 
> Interesting, the problem is only with 603, not 604. I think I might
> have broken something with the 603 SW TLB loading stuff which is
> a bit weird, I'll have a look. Thanks.

This fixes it to some extent... It gets to "press enter to activate
this console" but from there things don't work properly unless I
emulate a 604. I suspect there are still issues with the 603 SW
TLB mode.

--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -959,8 +959,13 @@ static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong msr)
 {
     CPUState *cs = CPU(ppc_env_get_cpu(env));
 
-    /* MSR:POW cannot be set by any form of rfi */
-    msr &= ~(1ULL << MSR_POW);
+    /* These bits cannot be set by RFI on non-BookE systems and so must
+     * be filtered out. 6xx and 7xxx with SW TLB management will put
+     * TLB related junk in there among other things.
+     */
+    if (env->excp_model &= POWERPC_EXCP_BOOKE) {
+            msr &= ~(target_ulong)0xf0000;
+    }
 
 #if defined(TARGET_PPC64)
     /* Switching to 32-bit ? Crop the nip */
@@ -990,7 +995,6 @@ void helper_rfi(CPUPPCState *env)
     do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1] & 0xfffffffful);
 }
 
-#define MSR_BOOK3S_MASK
 #if defined(TARGET_PPC64)
 void helper_rfid(CPUPPCState *env)
 {

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Hervé Poussineau]

Le 25/08/2016 à 07:33, Benjamin Herrenschmidt a écrit :
> On Thu, 2016-08-25 at 11:31 +1000, Benjamin Herrenschmidt wrote:
>>
>> Interesting, the problem is only with 603, not 604. I think I might
>> have broken something with the 603 SW TLB loading stuff which is
>> a bit weird, I'll have a look. Thanks.
>
> This fixes it to some extent... It gets to "press enter to activate
> this console" but from there things don't work properly unless I
> emulate a 604. I suspect there are still issues with the 603 SW
> TLB mode.
>
> --- a/target-ppc/excp_helper.c
> +++ b/target-ppc/excp_helper.c
> @@ -959,8 +959,13 @@ static inline void do_rfi(CPUPPCState *env, target_ulong nip, target_ulong msr)
>  {
>      CPUState *cs = CPU(ppc_env_get_cpu(env));
>
> -    /* MSR:POW cannot be set by any form of rfi */
> -    msr &= ~(1ULL << MSR_POW);
> +    /* These bits cannot be set by RFI on non-BookE systems and so must
> +     * be filtered out. 6xx and 7xxx with SW TLB management will put
> +     * TLB related junk in there among other things.
> +     */
> +    if (env->excp_model &= POWERPC_EXCP_BOOKE) {
> +            msr &= ~(target_ulong)0xf0000;
> +    }
>
>  #if defined(TARGET_PPC64)
>      /* Switching to 32-bit ? Crop the nip */
> @@ -990,7 +995,6 @@ void helper_rfi(CPUPPCState *env)
>      do_rfi(env, env->spr[SPR_SRR0], env->spr[SPR_SRR1] & 0xfffffffful);
>  }
>
> -#define MSR_BOOK3S_MASK
>  #if defined(TARGET_PPC64)
>  void helper_rfid(CPUPPCState *env)
>  {
>

Fixes: a2e71b28e832346409efc795ecd1f0a2bcb705a3
Reported-by: Hervé Poussineau <hpoussin@reactos.org>
Tested-by: Hervé Poussineau <hpoussin@reactos.org>

For the problem to press enter to "activate this console", this is another regression.
However, I was unable to pin-point it to a specific commit (too much interwinded regressions)
It was working in 2.6.0 (commit a2e71b28e832346409efc795ecd1f0a2bcb705a3)

Hervé

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Benjamin Herrenschmidt]

On Thu, 2016-08-25 at 22:14 +0200, Hervé Poussineau wrote:
> 
> Fixes: a2e71b28e832346409efc795ecd1f0a2bcb705a3
> Reported-by: Hervé Poussineau <hpoussin@reactos.org>
> Tested-by: Hervé Poussineau <hpoussin@reactos.org>
> 
> For the problem to press enter to "activate this console", this is
> another regression.
> However, I was unable to pin-point it to a specific commit (too much
> interwinded regressions)
> It was working in 2.6.0 (commit
> a2e71b28e832346409efc795ecd1f0a2bcb705a3)

Well, if you can get me that kernel source, I may have more chances to
track this down ;-)

Cheers,
Ben.

Re: [Qemu-devel] ppc: regression in 2.7.0-rc3 on rfi/rfid/hrfi instructions

[Hervé Poussineau]

Le 25/08/2016 à 23:27, Benjamin Herrenschmidt a écrit :
> On Thu, 2016-08-25 at 22:14 +0200, Hervé Poussineau wrote:
>>
>> Fixes: a2e71b28e832346409efc795ecd1f0a2bcb705a3
>> Reported-by: Hervé Poussineau <hpoussin@reactos.org>
>> Tested-by: Hervé Poussineau <hpoussin@reactos.org>
>>
>> For the problem to press enter to "activate this console", this is
>> another regression.
>> However, I was unable to pin-point it to a specific commit (too much
>> interwinded regressions)
>> It was working in 2.6.0 (commit
>> a2e71b28e832346409efc795ecd1f0a2bcb705a3)
>
> Well, if you can get me that kernel source, I may have more chances to
> track this down ;-)

Of course, I don't have the exact source :)

Here is the dmesg of the running system on QEMU 2.6.0:

Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb
Total memory = 128MB; using 512kB for hash table (at c0300000)
Linux version 2.4.18 (root@Juneau-lug) (gcc version 2.95.4 20011002 (Debian prerelease)) #5 Wed May 21 23:50:43 AKDT 2003
PReP architecture
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=/dev/ttyS0,9600 console=tty0 ether=5,0x210,eth0 ether=11,0x300,eth1 ramdisk_size=8192 root=/dev/ram
time_init: decrementer frequency = 68.925649 MHz
Console: colour VGA+ 80x25
Calibrating delay loop... 691.40 BogoMIPS
Memory: 124740k available (1656k kernel code, 856k data, 248k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Fixup res 2 (200) of dev 00:0d.0: 31000000 -> f1000000
Fixup res 6 (7201) of dev 00:0d.0: f1010000 -> b1010000
Setting PCI interrupts for a "Mesquite cPCI (MCP750)"
PCI: Cannot allocate resource region 0 of PCI bridge 0
PCI: resource is 0..fffffff (100), parent c020105c
PCI:00:0d.0: Resource 2: f1000000-f1000fff (f=200)
PCI: Switching off ROM of 00:0d.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
request_module[parport_lowlevel]: Root fs not mounted
lp: driver loaded but no devices found
rtc: I/O port 112 is not free.
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
hdc: IRQ probe failed (0x0)
hdd: IRQ probe failed (0x0)
hdd: IRQ probe failed (0x0)
ide1 at 0x170-0x177,0x376 on irq 13
hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
ide-floppy driver 0.97.sv
loop: loaded (max 8 devices)
ide-floppy driver 0.97.sv
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Macintosh non-volatile memory driver v1.0
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb.c: registered new driver hid
hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 852k freed
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 248k init 48k pmac 8k chrp 12k openfirmware

According to "INSTALLING LINUX" section of http://www.juneau-lug.org/sandalfoot.php
This is a 2.4.18 Debian kernel (2.2 or 3.0, I didn't understood), where is applied a patch from Sven Dickert, available at http://www.remote.org/sven/ppc/40p.patch

Hervé