Re: ARM atomic question

[Mark Tinguely <tinguely_(_at_)_casselton_(_dot_)_net>]

>  > 	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?

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.

Thanks,

--Mark.
_______________________________________________
freebsd-arm_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe_(_at_)_freebsd_(_dot_)_org"