[OpenBIOS] [PATCH 0/3] sparc64 cleanups v1

[Igor Kovalenko]

On Fri, May 28, 2010 at 12:42 AM, Blue Swirl <blauwirbel at gmail.com> wrote:
> On Thu, May 27, 2010 at 4:57 PM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> Blue Swirl wrote:
>>
>>> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
>>> <igor.v.kovalenko at 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.

I'll take a look at this issue.

>
> The lesson here is also that subtle assumptions like this should be documented.
>



-- 
Kind regards,
Igor V. Kovalenko