* Re: [hppa-linux] syscall work
From: Mike Shaver @ 1999-03-25 23:55 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <36FAC708.362B@cup.hp.com>
Bob Pflederer wrote:
>
> > OK, I'm convinced. I've changed unistd.h to use 0xC0000404 (on the next
> > page) for the syscall gateway, although we can easily change it back.
>
> Isn't the next page at 0xc0001000? Or does linux have some concept of
> 1k "pages" even though pages in the TLB are 4k?
Brain-o. 0xC0001004 it is.
While we're on the topic, though: why 0xC0000004 and not 0xC0000000 as
the target address? (Although there are other bugs, like ``ldo 5,%r22''
instead of ``ldi 5,%r22'' in the Assembler Ref as well, so maybe this is
another?)
Mike
--
92501.80 83731.86
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Alan Cox @ 1999-03-26 0:42 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903252340.RAA08466@helgaaspc.rsn.hp.com>
> Of course, you don't *have* to share those mappings, but you will
> have more TLB misses and (unless you're careful about virtual address
> allocation for aliasing) more cache flushing.
Ok - yes so we do want a different address.
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Bjorn Helgaas @ 1999-03-25 23:40 UTC (permalink / raw)
To: hppa-linux
>> I'd suggest *not* using the same gateway page address as HP-UX. If you
>> do, you won't be able to develop a later kernel extension to support
>> HP-UX binaries, unless you allocate syscall numbers carefully.
>
>Doesn't that depend which gateway page you map into each application ?
Here's one of the subtleties of PA-RISC VM. Under HP-UX, there's only one
mapping (space 0, offset 0xC0000000) that is shared by all applications.
The libc stub branches to (%sr7,0xC0000000), and %sr7 always contains
a zero while running user apps.
Sharing a mapping between applications is a performance win, because
you can share the TLB entry and you can share the physical page without
worrying about any cache flushing issues. Since PA-RISC has virtually-
indexed caches, you can only share physical pages under limited conditions
-- see appendix F in the 2.0 arch book.
Of course, you don't *have* to share those mappings, but you will
have more TLB misses and (unless you're careful about virtual address
allocation for aliasing) more cache flushing.
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Bob Pflederer @ 1999-03-25 23:30 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <36FAA595.DB56B012@netscape.com>
> OK, I'm convinced. I've changed unistd.h to use 0xC0000404 (on the next
> page) for the syscall gateway, although we can easily change it back.
Isn't the next page at 0xc0001000? Or does linux have some concept of
1k "pages" even though pages in the TLB are 4k?
-Bob
^ permalink raw reply
* [hppa-linux] libmilli and linker scripts
From: Mike Shaver @ 1999-03-25 22:34 UTC (permalink / raw)
To: hppa-linux
I'm making progress on getting the kernel to compile, and it's now
attempting to link, but I'm confounded by my expected foes:
1) millicode bits:
net/network.a(socket.o): In function `proto_init':
socket.o(.text+0x144): undefined reference to `$$dyncall'
and thousands more like it, and $$divI, $$divU and $$remU in the serial
code. Is there some millicode assembly we could purloin, or should we
write our own somehow? (Or maybe fix the compiler to do it all inline?)
2) the total absence of a linker script. Anyone have ideas on:
kernel-in-memory layout, preferably by section?
Mike
--
87277.19 78688.20
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Alan Cox @ 1999-03-25 23:05 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903251919.LAA01701@cllmail.cup.hp.com>
> I'd suggest *not* using the same gateway page address as HP-UX. If you
> do, you won't be able to develop a later kernel extension to support
> HP-UX binaries, unless you allocate syscall numbers carefully.
Doesn't that depend which gateway page you map into each application ?
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Stan Sieler @ 1999-03-25 21:27 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <36FAA595.DB56B012@netscape.com>
Mike writes:
> Anyone know what manual they're talking about? I'd like to find out
> what to do for syscalls that take more than 4 arguments, like mmap and
> recvfrom and sendto.
Sounds like the HP-UX Application Binary Interface (or
was it the Application Programming Interface...two different manuals) from the
Precision RISC Organization (or, more exactly,
from HP...but developed for PRO) would be quite useful. It (the
one that discusses system calls) may provide some
info about where parameters go.
Unfortunately, I'm miles away from my copy. Maybe someone
from HP can comment on the manual?
BTW, I like the different gateway address better than the different range.
--
Stan Sieler sieler@allegro.com
http://www.allegro.com/sieler.html
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Mike Shaver @ 1999-03-25 21:07 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903252046.OAA08061@helgaaspc.rsn.hp.com>
Bjorn Helgaas wrote:
> If Linux uses a different gateway page address than HP-UX (which I
> think is a good idea), why not use a strategy like that used for
> 64-bit HP-UX apps, where the kernel supplies the address in a
> register at application startup?
OK, I'm convinced. I've changed unistd.h to use 0xC0000404 (on the next
page) for the syscall gateway, although we can easily change it back.
The ``Assembly Language Reference Manual'' I have says:
Refer to the /HP-UX Reference/ manual for more information on HP-UX
system
calls.
Anyone know what manual they're talking about? I'd like to find out
what to do for syscalls that take more than 4 arguments, like mmap and
recvfrom and sendto.
Mike
--
81996.85 73813.97
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Bjorn Helgaas @ 1999-03-25 20:46 UTC (permalink / raw)
To: hppa-linux
Cary Coutant wrote
>
>I'd suggest *not* using the same gateway page address as HP-UX. If you
>do, you won't be able to develop a later kernel extension to support
>HP-UX binaries, unless you allocate syscall numbers carefully.
If Linux uses a different gateway page address than HP-UX (which I
think is a good idea), why not use a strategy like that used for
64-bit HP-UX apps, where the kernel supplies the address in a
register at application startup?
^ permalink raw reply
* Re: [hppa-linux] Qn on PA-RISC Page tables and TLB
From: Craig Hada @ 1999-03-25 20:31 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <Pine.LNX.3.96.990324225944.502B-100000@quark.ix.netcom.com>
>
>
> PA-RISC Arch 1.1 book says:
> On page 3-14:
>
> Exact form of these tables is s/w convention.
>
> Q. If the format is software convention, does that mean
> the fields within TLB slots are not defined by Hardware ?
> Though the book does seem to indicate what fields are needed
> in a pdir entry. Without knowing exact positions of various
> fields how would TLB entries be updated from pdir entries in
> memory ?
>
In the absense of a harware TLB walker, the page directory format can be
structured by software to fit its needs. However, the TLB miss handler
must reformat the bits to fit the format of the TLB insert instructions.
To get maximum performace from the system, the TLB miss handlers must be
made very efficient. The format of the page directory entry in the PA-RISC
Arch 1.1 book minimizes the work of the TLB miss handlers by aligning the
fields to match the format of the TLB insert instructions.
In order to enable the hardware TLB walker, the format of the page directory
must match the format from PA-RISC Arch 1.1 book. In addition, the memory
for the page directory must be equivalently mapped, power of two size aligned
(ie a page directory 1 MB in size must start on a 1 MB boundary), and
contiguous.
> Other interesting point to note is that PA-RISC does not
> define how many entries in the table etc. Very much unlike
> x86.
>
> -pkd
The number of entries in the page directory are a function of the amount of
memory and the amount of memory mapped I/O in the box. Since the hash
function is not perfect, the size of page directory can be tuned to meet
the system requirements.
-Craig
>
>
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe: send e-mail to hppa-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Mike Shaver @ 1999-03-25 20:12 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903251919.LAA01701@cllmail.cup.hp.com>
Cary Coutant wrote:
> I'd suggest *not* using the same gateway page address as HP-UX. If you
> do, you won't be able to develop a later kernel extension to support
> HP-UX binaries, unless you allocate syscall numbers carefully.
Well, my plan was to do what the MIPS guys have done (and others, like
maybe SPARC?):
syscall numbers 0 to 200-something are __NR_HP_syscall, and then the
Linux ones start at 1000. HP-UX binary emulation is something that I
really really want early on, because it will give us a functioning
userland while we're trying to get compiler and linker and glibc ports
complete and working.
But maybe you're right -- maybe we use one gateway page address for
HP-UX compat, and another for native-Linux syscalls. We have a lot more
flexibility in our system call mechanism than the other platforms did, I
think, so perhaps there's a better way.
It'd be nice to have hpux.o as a module for binary compatibility, when
we get there, but that's probably not so hard. Ponder...
The checked-in unistd.h has appropriate syscall numbering to support the
current plan, if you'd like to peek.
Mike
--
78101.27 70129.77
^ permalink raw reply
* Re: [hppa-linux] Document Priority?
From: Jason Eckhardt @ 1999-03-25 19:56 UTC (permalink / raw)
To: mickey; +Cc: hppa-linux
>
> hi
> looking at the released pdc/iodc docs i'm wondering what is in the missing
> chapters? is it possible to release the whole contents table?
> what are the plans for the rest of the book(s) ?
> and, is there any plan for "pa-risc IO architecture" release any soon?
The PDC/IODC docs posted are actually a subset of the chapters of the
PA-RISC I/O architecture doc. The first 8 or so chapters of the I/O
doc contain specific information about the various "Module" types (such
as processor modules, memory modules, I/O modules, bus converters, etc).
The last 4-5 chapters and appendices are the same as the PDC/IODC docs we
have.
I'm not sure why we were given only the subset (which pertains only to
the firmware) but I believe we can get a decent start with it. Eventually,
we will need the other information if we intend to have working device
drivers, etc. Of course, we can trudge through MkLinux code to figure some of
it out, but I'd much prefer the doc.
Jason.
^ permalink raw reply
* Re: [hppa-linux] syscall work
From: Cary Coutant @ 1999-03-25 19:23 UTC (permalink / raw)
To: hppa-linux
I'd suggest *not* using the same gateway page address as HP-UX. If you
do, you won't be able to develop a later kernel extension to support
HP-UX binaries, unless you allocate syscall numbers carefully.
Cary Coutant
Hewlett-Packard Co.
Application Delivery Lab
^ permalink raw reply
* Re: [hppa-linux] Qn on PA-RISC Page tables and TLB
From: Grant Grundler @ 1999-03-25 17:18 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <Pine.LNX.3.96.990324225944.502B-100000@quark.ix.netcom.com>
Kumar wrote:
...
> Other interesting point to note is that PA-RISC does not
> define how many entries in the table etc. Very much unlike
> x86.
The CPU pdir can vary in size. For a HW walker, it must be allocated
in physically configuous memory, this pretty much fixes the size
once it's setup.
The size of the CPU PDIR is determined mostly by memory size, amount
of I/O space required (Legacy PA requires memory mapped I/O), and
some fudge factor. Sizing it to allow a HW walker find all physical
mappings is good for performance. I assume this also helps SW TLB
handlers by reducing hash collisions. However, I'm not the expert
on CPU pdir.
K, C-class, and T600 also have an I/O pdir. This is only useful for
systems with more than 4GB (3.75GB?) of physical memory since PA
(and current PCI devices) can only use 32-bits of addressing.
The I/O pdir size depends on how much I/O one wants to allow mapped
at any given time and it too must be physically contigous.
16/th to 8th of physical memory seems to be a pretty good rule of thumb.
For now, I would say ignore the I/O pdir until hppa-linux has a
login prompt. If the OS doesn't use the I/O pdir, it just implies
the DMA is not coherent with Processor activity - just like on
an x86 box. I haven't studied Linux I/O subsytem enough to know
where/how to integrate support for an I/O pdir. I hope the HP-UX
docs released help explain this - search for keyword "CDIO".
grant
^ permalink raw reply
* Re: [hppa-linux] Document Priority?
From: Michael Shalayeff @ 1999-03-25 16:49 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903221856.KAA04931@meow.sr.hp.com>
hi
looking at the released pdc/iodc docs i'm wondering what is in the missing
chapters? is it possible to release the whole contents table?
what are the plans for the rest of the book(s) ?
and, is there any plan for "pa-risc IO architecture" release any soon?
thanks,
--
paranoic mickey (my employers have changed but, the name has remained)
^ permalink raw reply
* Re: [hppa-linux] Qn on PA-RISC Page tables and TLB
From: Bjorn Helgaas @ 1999-03-25 15:59 UTC (permalink / raw)
To: hppa-linux
> Exact form of these tables is s/w convention.
>
>Q. If the format is software convention, does that mean
> the fields within TLB slots are not defined by Hardware ?
There is no architectural definition of hardware TLB miss handling,
and most PA-RISC processors do not implement it.
On the ones that do support hardware TLB miss handling, the hardware
expects a certain format, and it is essentially the one given in the
examples in the architecture books. The hardware TLB walker expects
a hash table of PDIR entries (indexed by a function of the space and
offset), and it only looks at the entries in the table. Hash collisions
are resolved by a linked list, and the hardware does not walk the list;
this is left for the software miss handler.
^ permalink raw reply
* [hppa-linux] Qn on PA-RISC Page tables and TLB
From: Kumar @ 1999-03-25 7:10 UTC (permalink / raw)
To: hppa-linux; +Cc: kumar
PA-RISC Arch 1.1 book says:
On page 3-14:
Exact form of these tables is s/w convention.
Q. If the format is software convention, does that mean
the fields within TLB slots are not defined by Hardware ?
Though the book does seem to indicate what fields are needed
in a pdir entry. Without knowing exact positions of various
fields how would TLB entries be updated from pdir entries in
memory ?
Other interesting point to note is that PA-RISC does not
define how many entries in the table etc. Very much unlike
x86.
-pkd
^ permalink raw reply
* [hppa-linux] syscall work
From: Mike Shaver @ 1999-03-25 17:33 UTC (permalink / raw)
To: hppa-linux
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
I've committed a mildly updated version of unistd.h, which contains the
magic _syscall<n> macros. I'm sure I'm doing silly things, so you
should all point and laugh as approriate.
I've attached the relevant chunks for your easy mocking.
Mike
--
22863.99 20474.77
[-- Attachment #2: syscall.c --]
[-- Type: text/plain, Size: 2220 bytes --]
#define syscall_prolog \
register long __res __asm__("%r22"); \
register long __err __asm__("%r28");
#define syscall_epilog(type) \
if (__err == 0) \
return (type) __res; \
errno = __res; \
return -1;
#define _syscall0(type,name) \
type name(void) \
{ \
syscall_prolog; \
__asm__ volatile ("ldil L%%0xC0000004,%%r1\n\t" \
"ble R%%0xC0000004(%%sr7,%%r1)\n\t" \
"ldo %2,%%r22" \
: "=r" (__res), "=r" (__err) \
: "i" (__NR_##name)); \
syscall_epilog(type); \
}
#define _syscall1(type,name,atype,a) \
type name(atype a) \
{ \
syscall_prolog; \
__asm__ volatile ("ldo %2,%%arg0\n\t" \
"ldil L%%0xC0000004,%%r1\n\t" \
"ble R%%0xC0000004(%%sr7,%%r1)\n\t" \
"ldo %3,%%r22" \
: "=r" (__res), "=r" (__err) \
: "i" (__NR_##name), "r" ((long)a)); \
syscall_epilog(type); \
}
^ permalink raw reply
* Re: [hppa-linux] the cvs thingy
From: Mike Shaver @ 1999-03-25 13:53 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <36F98997.130DE72A@america.net>
Ed June wrote:
> $ cvs -z3 checkout hppa-linux
> cvs server: cannot find module `hppa-linux' - ignored
> cvs [checkout aborted]: cannot expand modules
cvs -z3 co linux
Mike
--
9805.70 8095.76
^ permalink raw reply
* [hppa-linux] the cvs thingy
From: Ed June @ 1999-03-25 0:55 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903242116.NAA25002@gatekeeper.equator.com>
>
Hmm, am I doing this correct ?
$ export CVSROOT=':pserver:anonymous@sod.res.cmu.edu:/home/cvs/hppa'
$ cvs login
(Logging in to anonymous@sod.res.cmu.edu)
CVS password:
$ cvs -z3 checkout hppa-linux
cvs server: cannot find module `hppa-linux' - ignored
cvs [checkout aborted]: cannot expand modules
--
Ed June
buggz@america.net
Linux: An open choice for free people worldwide.
^ permalink raw reply
* Re: [hppa-linux] Linux Kernel and PA-RISC
From: Jason Eckhardt @ 1999-03-24 21:16 UTC (permalink / raw)
To: hppa-linux
>
>
> My understanding of PA equivalent:
>
...
>
> One other question is whats happening to space registers when
> you are running in real mode ?
>
In real mode the space register field of the load/store/cache instructions
is ignored so that the effective address is just the 32-bit offset.
Jason.
^ permalink raw reply
* Re: [hppa-linux] GCC and static branch prediction
From: Alan Cox @ 1999-03-23 17:21 UTC (permalink / raw)
To: hppa-linux
In-Reply-To: <199903231612.LAA02124@caliban.physics.utoronto.ca>
> A few of us were discussing recently a way to take advantage of static
> branch prediction in the PA-RISC architecture. The problem is that there
> is no ANSI C construct for specifying whether a branch is likely taken,
> or likely not taken.
We already sort of do this for the dynamic branch predictions. The gcc
code generator writes faster code for one path of an if/else in general
anyway. So you just get the pa-risc back end to output the right assumptions.
I'd start by walking though
^ permalink raw reply
* [hppa-linux] GCC and static branch prediction
From: Christopher Neufeld @ 1999-03-23 16:12 UTC (permalink / raw)
To: hppa-linux
Hi,
A few of us were discussing recently a way to take advantage of static
branch prediction in the PA-RISC architecture. The problem is that there
is no ANSI C construct for specifying whether a branch is likely taken,
or likely not taken.
I wonder, though, if we can't maybe throw something together which
would work "well enough".
What I'm thinking of is getting a couple of assembly NOPs (ones which
are not usually output by gcc / gas), and making macros for them to
inline the assembly into a C function.
[ ... do some stuff ... ]
if (error) {
PARISC_BRANCH_LIKELY_TAKEN; /* i.e. usually don't enter the if() */
[ ... do some more stuff ... ]
}
[ ... do some more stuff ... ]
or,
while (locked(ptr)) {
do_other_things();
}
PARISC_BRANCH_LIKELY_TAKEN; /* i.e. usually repeat the loop */
Now, if we can make an insn pattern which matches the noop to the branch
which came just before it, we can get the optimizer to produce the
correct static branch prediction on the preceding operation (and also,
while it's optimizing, delete the NOP). For other architectures, the
macros are defined away, and the macros need only be used in places where
we really need the extra boost (preferably only in the arch/parisc
directories, imagine Linus' face if we started dropping these macros all
over the kernel!).
As I see it, there are a few things to worry about. Unrolling loops;
if(){}else{} clauses where the optimizer changes the sense of the test
for reasons known to itself, resulting in pessimized static branch
settings; correct interpretation of nested, optimized branches; any glue
code which is stuck on at the beginning and end of asm() statements which
may not be discarded even when the asm() consists solely of a NOP;
probably many others.
Any thoughts?
--
Christopher Neufeld neufeld@physics.utoronto.ca
Home page: http://caliban.physics.utoronto.ca/neufeld/Intro.html
"Don't edit reality for the sake of simplicity"
^ permalink raw reply
* [hppa-linux] Linux Kernel and PA-RISC
From: Kumar @ 1999-03-23 6:57 UTC (permalink / raw)
To: hppa-linux; +Cc: kumar
This is a long one. So bear with me.
In the process of trying to know more about PA-RISC, I ended up
doing a following comparative analysis between PA and 80386:
Take a 80386 -
Make segment registers 32 bits wide and instead of defining
how much memory is covered by each segment using Global descriptor
table etc, make each segments of same size that is 32 bits.
Take out the special meaning assigned to segment registers by hardware
i.e no CS, DS, ES etc etc. Call these new segment registers "spaces"
each capable of addressing 4 Gig of memory.
So now we have this 2 dimensional virtual address space, %sr.%offset.
Instead of going through a pdir->page_table->page combination as done
in x86, just use a TLB black box:
%sr.%offset-------->[TLB black-box]---------->a physical page in
a flat physical address space.
One of the issues while porting Linux to 80386 would be how to implement
this TLB black-box.
I expect folks to correct me if I have faltered or made any wrong assumptions
so far.
On a x86 Linux box, at any given time following is happening.
Kernel space is defined by 2 segments in GDT, one each for code and data.
User space is defined by 2 segments in GDT, one each for code and data.
There might be others ( Like stack, though i believe u can use data segment).
When a process makes a syscall going through an interrupt gate:
One of things that we do is to save every thing ( HW state), change
CS and DS to those of kernel space, giving a 32 bit virtual address and
depend on pdir->page_table->page mumbo jumbo to start executing and fetching
instruction in kernel.
My understanding of PA equivalent:
Since there is no special meaning (except %sr0 which i think is
used for branch and link space) to any space registers, Juse use
by convention a particular space register and a value in this space
register to define Kernel space.
There is no segment level protection here ?
All protection is through protection identifiers and other fields
in tlb entry data structures. One of the important field here is
privilege level of the page defined by a particular tlb entry.
A process makes a syscall by executing a gate instruction on a
privileged page, that braches to a syscall entry point in kernel
and also increases your privilege level.
To move from real mode to Virtual mode:
Set things up ( i.e. create pdir and map everything correctly)
Hope you are executing on a page thats equivalently mapped.
Turn on I and D bits in PSW and you are in protected mode.
One other question is whats happening to space registers when
you are running in real mode ?
I hope, this "magnum opus" is enough for today :-)
-pkd
^ permalink raw reply
* Re: [hppa-linux] Document Priority? (fwd)
From: Jason Eckhardt @ 1999-03-22 21:46 UTC (permalink / raw)
To: billk, jason; +Cc: hppa-linux
>
> | 4. Any bug reports that MUST be worked around by the OS. In particular,
> | I believe the S-chip had problems that could not be ignored by the OS.
>
> I'm working on PCXL and other CPU docs. I'll try to find someone that
> remebers the PCXS chip.
>
I personally don't care much about S, but apparently the 720 and perhaps one
or two other models used it. I know some of the people who tested the
bootstrap code were running on 720's. We do want to cover a large portion
of the spectrum of 700's and 800's....
>
> I'll try. Assuming I can make PS from TROFF and TeX.
>
For TeX it's trivial, there is at least one well known .dvi to .ps
converter. Use your favorite search engine to find "dvips". Then perform
"dvips -f < xyzzy.dvi > xyzzy.ps".
As for TROFF, I believe GROFF can emit PostScript.
Jason.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox