Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Nov 1996 11:35:12 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        peter@spinner.dialix.com (Peter Wemm)
Cc:        toor@dyson.iquest.net, phk@critter.tfs.com, freebsd-smp@freebsd.org
Subject:   Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h
Message-ID:  <199611251835.LAA22875@phaeton.artisoft.com>
In-Reply-To: <199611251327.VAA01291@spinner.DIALix.COM> from "Peter Wemm" at Nov 25, 96 09:27:57 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> OBTW, easy question.  Is it safe to do a:
> 	movl	%cr3, %eax
> 	movl	%eax, %cr3
> .. from a non-spl-maskable interrupt handler?
> 
> I'm thinking in terms of a lightning quick interprocessor interrupt to
> force all cpu's to do an invltlb().
> 
> So far as I can see from a quick scan of the code, the only real loads of
> %cr3 are during cpu_switch(), initialisation, and tlb flushes.  cpu_switch()
> does it from inside cli/sti so it's safe, init code is irrelevant at this
> point, and I think the tlb flush is implicitly reentrant since it's
> not changing the register.
> 
> Have I missed something?

Why do you need to force all CPU's to do an invltlb()?

Is this to handle bus master DMA target memory?

Or is this for IPC?

IMO, the first can be handled by declaring the targets non-cacheable,
and dealing with the "transfer complete" on the CPU that initiated
the I/O.

For IPC, there should be a scratch area which is marked non-cacheable
in the first place and mapped into all CPU's address spaces.

For the interrupt handlers themselves, the events should be queued,
but not handled except in upper level code.  The interrupts need to
be virtualized (I know, I know, this gets back into the discussion
about "changing the way non-SMP FreeBSD handles interrupts" that
we didn't want to have).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611251835.LAA22875>