Opened 14 years ago

Closed 14 years ago

#157 closed defect (fixed)

The ia64 kernel survives the fault1 kernel test

Reported by: Jakub Jermář Owned by:
Priority: major Milestone: 0.4.2
Component: helenos/kernel/ia64 Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description

The ia64 kernel survives the fault1 kernel test. This is however not expected as that test is accessing page 0, which should not be mapped.

Change History (3)

comment:1 by Jakub Jermář, 14 years ago

Quite interesting, Simics does not generate any trap when accessing virtual address 4 as if there was a mapping for that in TLB. That does not seem to be the case however, as there is only a mapping for PA2KA(0). When run in Ski, the test behaves as expected and the kernel panics.

comment:2 by Jakub Jermář, 14 years ago

I think the key to this ticket is the answer to why Simics, after reaching paging_sart, still maps address 4:

simics> cpu0.tlb-status
Data TLB
—-p-ma-a-d-pl-ar———————ppn-ed-ps———key———————vpn———rid
TR 1 0 1 1 0 3 0 1 1c 0 e000000000000 0

1 4 1 1 0 3 0 1 1c 0 e002000000000 0
1 4 1 1 0 3 ffffc000 1 1a 0 e001000000000 0
1 4 1 1 0 3 f0000 1 1c 0 e0000000f0000 0


Instruction TLB
—-p-ma-a-d-pl-ar———————ppn-ed-ps———key———————vpn———rid
TR 1 0 1 1 0 3 0 1 1c 0 e000000000000 0


simics> logical-to-physical 4
4

comment:3 by Jakub Jermář, 14 years ago

Resolution: fixed
Status: newclosed

Fixed in changeset:head,204.

The problem was that addresses with both VRN 0 (adresses with the MSB 3 bits 0) and 7 (addresses with the MSB 3 bits 1) were associated with RID 0 (the RID used by the kernel).

The VPN in TLB contains the VRN, but at least the Simics model does not take that into account,
so it considered address 4 to be matching as well.

Note: See TracTickets for help on using tickets.