On Thu, May 27, 2010 at 4:57 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko igor.v.kovalenko@gmail.com wrote:
One code cleanup and another pci host bridge remap change, the latter requires qemu update with patch already posted to qemu list.
v0->v1: added missing patch moving asi.h to arch includes
Thanks, applied all.
Whilst updating to OpenBIOS SVN and qemu git head to test these patches, I've found a regression with qemu-system-sparc64 and debian-504-sparc-netinst.iso. Rather than getting to the end of the kernel boot and being unable to mount the root filesystem, instead I now get the following fatal trap message:
[ 42.493402] Console: switching to mono PROM 128x96 [ 63.440200] [drm] Initialized drm 1.1.0 20060810 [ 63.542123] su: probe of ffe2dea0 failed with error -12 [ 63.690331] brd: module loaded [ 63.787034] loop: module loaded [ 63.863989] Uniform Multi-Platform E-IDE driver [ 63.961215] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 64.115119] mice: PS/2 mouse device common for all mice [ 64.234482] usbcore: registered new interface driver usbhid [ 64.359397] usbhid: v2.6:USB HID core driver [ 64.462167] TCP cubic registered [ 64.539714] NET: Registered protocol family 17 [ 64.642969] registered taskstats version 1 [ 64.737822] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) qemu: fatal: Trap 0x0068 while trap level (5) >= MAXTL (5), Error state pc: 0000000000424d18 npc: 0000000000424d1c General Registers: %g0-3: 0000000000000000 0000000008000000 0000000000004000 0000000000000002 %g4-7: 00000000000003ff 0000000000000001 0000000000000020 0000000000004000
Current Register Window: %o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %o4-7: 0000000000000000 0000000000000000 00000000fffd3ef0 0000000000000000 %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f32: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f36: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f40: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f44: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f48: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f52: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f56: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f60: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 00000414 ccr: 00 (icc: ---- xcc: ----) asi: 82 tl: 5 pil: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate: 2 cleanwin: 0 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 Aborted
Digging deeper, it seems that this was something that was introduced earlier than the last set of patches. Reverting to OpenBIOS SVN r777 and using 'git bisect', I can identify the offending commit in qemu git as 2aae2b8e0abd58e76d616bcbe93c6966d06d0188 "sparc64: fix pstate privilege bits". Does that help at all?
Yes, bisection results are usually very helpful, thanks.
I think the problem is that previously psrs was always 1 and PSR_HYPV always set, so maximally permissive MMU_HYPV_INDEX was always selected by cpu_mmu_index (bug!). Also because PSR_HYPV is no longer set, some checks in translate.c indicate privilege violations.
The logic was previously such that if the CPU does not have a hypervisor mode, for compatibility, supervisor mode would also select hypervisor mode (or at least that was my intention and probably Igor wasn't aware of this, sorry). Now that they are separate, CPUs without hypervisor mode must be handled differently. Perhaps this commit should be reverted, the fix won't be so trivial.
The lesson here is also that subtle assumptions like this should be documented.