lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<stekern>
ysionneau: there are no such thing as non-trivial tlb misses, everything else are pagefaults ;)
Gurty has quit [Ping timeout: 260 seconds]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #m-labs
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #m-labs
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #m-labs
Gurty has joined #m-labs
<ysionneau>
stekern: ahah, here I have trivial and non trivial ones :p
<ysionneau>
I have those which needs walking the page table
<ysionneau>
and those (the trivial ones) which needs only to add an offset to get the paddr
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 265 seconds]
nicksydney has joined #m-labs
nicksydney_ has quit [Ping timeout: 265 seconds]
lekernel has joined #m-labs
<stekern>
ysionneau: so you are actually running the tlb handler with the mmu enabled? doesn't that get hairy if you don't have the pagetables in the tlbs?
<ysionneau>
stekern: the non-trivial (walking page table) miss handling runs with mmu enabled
<ysionneau>
the same way that managing the page table outside of any tlb miss (inserting/removing/updating page tables by the internal memory mangement system) is working with mmu enabled as well
<ysionneau>
this way, both work the same way
<ysionneau>
which means for instance I only put virtual addresses in the page tables (except PTE of course)
<ysionneau>
BUT I take good care of using "trivial" virtual addresses only in the page tables
<ysionneau>
so that a non-trivial tlb miss will then run the tlb handler (in C) with mmu enabled, will walk the page table
<ysionneau>
and could only provoke trivial tlb misses
<ysionneau>
which will be resolved with mmu disabled
<ysionneau>
so no tlb miss infinite storm
<ysionneau>
it can only be nested once : a non trivial tlb miss generating a trivial tlb miss while walking the page table
<ysionneau>
to be more clear, the "trivial" virtual addresses are addresses in this range : 0xc000.0000-0xc800.0000
<ysionneau>
this is a virtual window over the entire physical ram
<ysionneau>
(physical ram size is 0x0800.0000)
<ysionneau>
so I name those "trivial" because translating from virtual to physical is "trivial" : it's just PA = VA - 0xc000.0000 + 0x4000.0000
<stekern>
but why?
<ysionneau>
the cool thing is that kernel is loaded at the very start of physical AND virtual memory, both 0x4000 and 0xc000
<ysionneau>
so that any kernel text or data tlb miss will be trivial
<stekern>
my point with, "there are only trivial tlb misses" is that it's always a trivial operation (unless it generates a pagefault)
<stekern>
why make it complicated by allowing it to generate double faults?
<ysionneau>
well we don't use the same wording
<ysionneau>
that's all
<ysionneau>
I differenciate between the misses that need page table walking and the misses that don't
<stekern>
"walking the pagetables" is what the tlb handler does
<ysionneau>
I call one trivial and one non trivial
<ysionneau>
no
<ysionneau>
there are two cases
<stekern>
it's 2 loads, IMO trivial ;)
<stekern>
if there are entries missing in the pagetables, that's non-trivial => pagefault
<ysionneau>
in the assembly code there is a check , if va is contained inside the 0xc000.0000-0xc800.0000 then the PA is calculated and the TLB content is updated
<ysionneau>
if it's not, then the C function is called and the page table is walked
<stekern>
2 loads, assuming you have 2-level pagetables
<ysionneau>
you are describing a different scheme that the one I implemented
<ysionneau>
and I don't know how to implement easily the one you are describing
<ysionneau>
what addresses do you put inside the page table ? virtual or physical?
<ysionneau>
(I am not talking about PTE)
<ysionneau>
if you put virtual addresses inside the page table, then the tlb handler needs to run with mmu enabled, then what happens if walking the page table generates a tlb miss ? it could then be infinite nested tlb misses
<ysionneau>
if then you decide to have a very simple tlb handler which runs with mmu disabled
<ysionneau>
and only put physical addresses in the page table
<ysionneau>
then how do you manage the page table during the real-life of the kernel which runs with mmu enabled?
<ysionneau>
how do you dereference the physical pointers?
<ysionneau>
maybe I am missing something here but I honestly don't know how do to differently than I am doing right now
<stekern>
the address to the pagetable has to be physical in that case
<stekern>
but think about that the hardware might require that, so it's not an insane constraint
<stekern>
(if you have hw tlb refills)
<ysionneau>
well I know it makes sense for hw tlb refills
<ysionneau>
but I don't have it
<stekern>
I've got to run, I'll try to elaborate later
<ysionneau>
so my issue then is: how do I manage the page table if it contains physical addresses ?
<ysionneau>
I don't know how to solve that
<ysionneau>
therefore my choice ^^
<ysionneau>
ok thanks for this discussion :)
<ysionneau>
see you later !
<stekern>
you handle it by just adding/subtracting the offset
<stekern>
as you do in your "trivial" tlb miss handler
<ysionneau>
stekern: ah yes indeed
<ysionneau>
ok now I got it
<ysionneau>
then I agree I could have done it that way as well
xiangfu has quit [Quit: leaving]
<ysionneau>
but then there is the "existing code base" constraint
<ysionneau>
I'm reusing generic pmap code which has been done for software managed tlb (ppc booke, mips)
<ysionneau>
and this code seems to work with page tables containing virtual addresses
<ysionneau>
I had no choice on this one
<ysionneau>
or I would have to duplicate all the code just to change that
<ysionneau>
which indeed is a small change
<ysionneau>
just one or 2 places add a macro to translate
<ysionneau>
11:42 < ysionneau> and this code seems to work with page tables containing virtual addresses < I am not 100% sure about that, but I think so
<ysionneau>
and since there is a macro call, to use physical addresses the only thing to do would be to #define POOL_PHYSTOV(a) (a)
<ysionneau>
that would break the meaning of the macro, because POOL_PHYSTOV would then provide physical instead of virtual
<ysionneau>
but it's technically feasible
<ysionneau>
just not so "clean"
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
<stekern>
if it makes more sense to keep the pagetable address virtual, you can of course do the add/subtract in the tlb miss handler instead
sh4rm4 has joined #m-labs
<ysionneau>
walking the page table with mmu disabled and translate virtual addresses directly instead of tlb-missing
<ysionneau>
that would be faster indeed
<ysionneau>
sounds like an all-win improvement :)
<ysionneau>
I think I will implement that
<ysionneau>
thanks for the help :)
sh4rm4 has quit [Remote host closed the connection]
<stekern>
+ you avoid issues with the "bad address" being trashed by the double fault (I can't remember how your mmu did that, but I assume it doesn't support being nested)
<ysionneau>
well since I put bad address in a GPR before having a chance to generate a nested exception, and since I save registers upon exception
<ysionneau>
then I was not losing the "bad address" upon nested tlb miss
<ysionneau>
it was indeed overwritten in the "mmu registers"
<ysionneau>
but it was still in the GPR
<stekern>
ok, but you can ignore that anyway ;)
<ysionneau>
yep with your idea there should be no more nested tlb miss anymore
<ysionneau>
except indeed in the "fault" path
<stekern>
yes, but that's running in "normal kernel mode"
<ysionneau>
yes
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
Alarm has joined #m-labs
sh4rm4 has joined #m-labs
<stekern>
and thanks to you to, I'm getting some interesting insights into netbsd I wouldn't have otherwise
sh4rm4 has quit [Remote host closed the connection]
<ysionneau>
:)
<ysionneau>
stekern: was openrisc accepted in gsoc ?
<ysionneau>
I've seen discussions about a gsoc project to port a BSD to openrisc
<ysionneau>
I think it was openbsd or freebsd
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
jkx has quit [Read error: Connection reset by peer]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
jkx has joined #m-labs
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
<stekern>
ysionneau: I think they do the announcement the 24th, and I believe it was a freebsd port that was on the list
<stekern>
I've been pre-occupied with a non-openrisc project the last couple of months though, I've set out on a mission to do a linux port for eco32 from scratch.
<stekern>
it's almost "done" now though
<larsc>
toolchain and everything?
<stekern>
there was a binutils and gcc-4.5.x in existance, but it was a bit buggy, so I updated it to 4.8.x and straightened out the worst bugs.
<stekern>
uClibc I had to do of course
<stekern>
the processor itself is yet-another-opensource-risc story, designed with simplicity in mind
<lekernel>
don't want to touch misoc? :)
sh4rm4 has quit [Remote host closed the connection]
<stekern>
lekernel: I don't mind touching misoc, but how's that related to what I'm currently going on about? ;)
<lekernel>
well, we also have a lot of uclibc/binutils/gcc/linux problems
<lekernel>
but very good RTL
<lekernel>
if every projects fixes only one of the problems, there'll never be a good open softcore platform. I could also move to MiSoC to OpenRISC, which I'm looking at atm...
<stekern>
ah, ok in that sense. Yes, sure, I might do that.
<stekern>
this eco32 side-project was mostly for pure personal reasons, I wanted to do a Linux port from scratch, neither openrisc nor lm32 presented that oppurtunity
<ysionneau>
when NetBSD will run on lm32, there will be a need for Linux to run on it as well
<ysionneau>
real linux
<ysionneau>
because it's cool to have a choice :)
<stekern>
otherwise, I agree, there's enough problems and parts of a softcore platform to support and maintain
<lekernel>
stekern, by the way, your milkymist-ng-mor1kx also meets timing here :)
<lekernel>
have you tried running it on a board?
<stekern>
ok, that's good to know, did you also update the mor1kx git submodule?
<lekernel>
I just did submodule init + submodule update
<stekern>
iirc, yes, I tried running it on a board. Never did anything fancy with it
<lekernel>
so it's commit 0ef9066a9d8259e932edb3c4ae9b266eaac77cb6 from Wed May 8 09:03:32 2013
<lekernel>
let me try with head
<stekern>
yes, do that
<lekernel>
are there any major changes you remember having to do? I wonder how hard it would be to just add a --openrisc option to make.py, that does everything (including switching compilers and crt)
<lekernel>
this way I wouldn't have to maintain multiple branches
<ysionneau>
that would be pretty awesome :)
<ysionneau>
to chose the cpu by just switching some parameter
<stekern>
but I just exchanged the lm32 stuff with or1k stuff, so you'll probably need to make the bios and sw aware that there might be different archs
<stekern>
which as a start would just mean to split it out in two different dirs
<lekernel>
head also meets timing
<lekernel>
oh, no, most of that code is C
<lekernel>
seems the changeset is small enough
<lekernel>
can probably be done with a few ifdefs and python-generated files
<stekern>
I meant, splitting out the files that there are changes to into two dirs
<stekern>
but I have no doubts you will figure out a good way yourself ;)
<lekernel>
it's also good that mor1k is parameterisable with verilog parameters and not that stupid lm32 include file
<stekern>
yes, that was one of the driving forces juliusb_ had when he started out designing it, or1200 also have the problem that it uses a lot of `defines
<lekernel>
Open Hardware Description License (OHDL)
<lekernel>
:)
<stekern>
yes, juliusb_ doesn't believe in mixing (L)GPL and rtl
<stekern>
=)
<lekernel>
yeah, (L)GPL is definitely for software
sh4rm4 has joined #m-labs
<ysionneau>
reading eco32 manual, it looks a loooot like lm32
<stekern>
personally, I've just been sticking to a bsd-like licens on my "own" rtl projects
sh4rm4 has quit [Remote host closed the connection]
<lekernel>
yeah, I moved everything to BSD now
<stekern>
ysionneau: or or1k, or niosII or micorblaze or mips or any other RISC machine out there ;)
<stekern>
it has an interesting mmu though, everything above 0xc0000000 is direct-mapped to 0x00000000 (i.e. doesn't go through the tlbs) and the tlbs are a 32-entries fully associative cache.
<ysionneau>
yes it's interesting
<ysionneau>
it makes me think about it, I could direct map 0xc000.0000-0xc800.0000 to 0x4000.0000-0x4800.0000 in the hardware
<ysionneau>
instead of using the tlb
<ysionneau>
that would be faster than handling tlb misses
sh4rm4 has joined #m-labs
aeris has quit [Read error: Operation timed out]
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
aeris has joined #m-labs
lekernel has quit [Ping timeout: 260 seconds]
lekernel has joined #m-labs
sh4rm4 has joined #m-labs
sh4rm4 has quit [Read error: Connection reset by peer]
bvernoux has joined #m-labs
sh4rm4 has joined #m-labs
sh4rm4 has quit [Read error: Connection reset by peer]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Read error: Connection reset by peer]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Read error: Connection reset by peer]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Read error: Connection reset by peer]
sh4rm4 has joined #m-labs
mumptai has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]