Date: Tue, 24 Mar 2009 19:40:20 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net Cc: freebsd-arm@freebsd.org Subject: Re: ARM atomic question Message-ID: <200903250040.n2P0eKHG085339@casselton.net> In-Reply-To: <20090325001649.GA84198@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903250040.n2P0eKHG085339>