ARM atomic question

[M. Warner Losh]

In message: <200903250040.n2P0eKHG085339 at casselton.net>
            Mark Tinguely <tinguely at casselton.net> writes:
: >  > 	1) how does this make it atomic? no one reads ras_start or ras_end
: >  > 	   to verify that it has not changed since I set it. This applies
: >  > 	   to all non-kernel atomic commands.
: 
: Oliver says:
: >  It is done by the kernel, when a trap occurs. They are issues with that
: >  code, though, which should be worked on.
: 
: Warner says:
: > The kernel looks at these addresses when it does a context switch.
: > Since there are no atomic ops, and you can't disable interrupts in
: > userland, we settle for the next worse thing: set critical sections
: > that are restarted if the kernel interrupts them.
: 
: The page is installed in the KVA writable with user permission, in machdep:
: 
: #ifdef ARM_CACHE_LOCK_ENABLE
: 	pmap_kenter_user(ARM_TP_ADDRESS, ARM_TP_ADDRESS);
: 	arm_lock_cache_line(ARM_TP_ADDRESS);
: #else
: 	m = vm_page_alloc(NULL, 0, VM_ALLOC_NOOBJ | VM_ALLOC_ZERO);
: 	pmap_kenter_user(ARM_TP_ADDRESS, VM_PAGE_TO_PHYS(m));
: #endif
: 
: Shouldn't a user be able to read/write to this address without a trap?

Yes.  In fact, that's the idea...

: I rewrote the cpu_throw() and cpu_switch(). Because:
: 
:  - combine the back end of cpu_throw() and cpu_switch.
:  - implemented pmap active bit for a CPU for future SMP.
:  - use the registers for per-cpu and TLS.
:  - ARMv6 does not need to flush tlb/cache on context switch:
:     - new ASID to identify 256 address spaces.
:     - the VIPT caches need some changes to pmap_fix_cache():
: 	- I don't want to make changes to pmap caching until we
: 	  resolve the pre-ARMv6 multiple KVA map caching issue.
: 	  I am running the pre-ARMv6 cache patch that I proposed (and
: 	  the new swtch.S)that I proposed with QEMU. The patch finds
: 	  remapping situations, but not those that caused cache problem.
:     - the PIPT cache does not need to do pmap_fix_cache() at all.
: 
: In rewiting the context change, I noticed that ARM_TP_ADDRESS/ARM_RAS_START/
: ARM_RAS_END addresses are saved and restored on context switches. Atomic
: commands don't look to see if the ARM_RAS_START is 0 and ARM_RAS_END is
: 0xffffffff before they put their addresses and do their change.

Right.  The kernel checks to see if a RAS is in flight.  If so, it
restores the pc to the start of the RAS.

Warner