Re: [hppa-linux] syscall work

Re: [hppa-linux] syscall work

[Bjorn Helgaas]

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?

Re: [hppa-linux] syscall work

[Mike Shaver]

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

Re: [hppa-linux] syscall work

[Stan Sieler]

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

Re: [hppa-linux] syscall work

[Bob Pflederer]

> 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

Re: [hppa-linux] syscall work

[Mike Shaver]

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

Re: [hppa-linux] syscall work

[Kumar]

On Thu, 25 Mar 1999, Mike Shaver wrote:

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

It does not matter as long as the gateway instruction is on the "special"
page. Probably one wants to put a nop before the gateway instruction.

-pkd

Re: [hppa-linux] syscall work

[Stan Sieler]

Hi,

There may be a reason to avoid the GATE instruction...I've seen some
HP PA-RISC systems where GATE has given way to simply
marking the "gateway" page as non-executable, and relying on a trap
handler to detect the gateway access.  The final result is the same...
an architected method of doing a system call.  (I can only conjecture 
that there is a reason for this...but I don't know what it is.)

Perhaps we can get an HP person to comment?

> It does not matter as long as the gateway instruction is on the "special"
> page. Probably one wants to put a nop before the gateway instruction.

-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: [hppa-linux] syscall work

[Michael Shalayeff]

Making, drinking tea and reading an opus magnum from Mike Shaver:
> 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
0xC0000004 is because hpux uses it (;
dunno about linux's binary emulation principles, but for
all bsd's the emulation parameters pointer is located in the proc
structure, which allows syscall emulation to work even all
the emulated os'es are using the same syscall entry point (on some
architectures there might be only one possible way for syscall, 4 xampl)

> 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?)
there is no such pa-risc instruction like ldi, it's a pseudo-asm-insn
which is actually ldo imm(0), rt
the whole pa-risc asm is full of pseudo-insns (like comb, comib, b(ranch))

cu

-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Re: [hppa-linux] syscall work

[Mike Shaver]

Michael Shalayeff wrote:
> Making, drinking tea and reading an opus magnum from Mike Shaver:
> > While we're on the topic, though: why 0xC0000004 and not 0xC0000000 as
> 0xC0000004 is because hpux uses it (;

Actually, I meant ``why does HP-UX use that address?''. =)

> dunno about linux's binary emulation principles, but for
> all bsd's the emulation parameters pointer is located in the proc
> structure, which allows syscall emulation to work even all
> the emulated os'es are using the same syscall entry point (on some
> architectures there might be only one possible way for syscall, 4 xampl)

Yes, we can do that too (and do on SPARC for Solaris at least, perhaps
SunOS as well), but it seems less efficient than just using different
syscall numbers or -- in the case of lovely hardware like PA-RISC --
using a different gateway address.

> > 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?)
> there is no such pa-risc instruction like ldi, it's a pseudo-asm-insn
> which is actually ldo imm(0), rt
> the whole pa-risc asm is full of pseudo-insns (like comb, comib, b(ranch))

That I know, but ``ldo 5,%r22'' is illegal syntax (according to gas and
the assembler reference, anyway), and that's what appears in the
Assembler Ref.

Mike

-- 
158640.45 72598.35

Re: [hppa-linux] syscall work

[Michael Shalayeff]

Making, drinking tea and reading an opus magnum from Mike Shaver:
> Michael Shalayeff wrote:
> > Making, drinking tea and reading an opus magnum from Mike Shaver:
> > > While we're on the topic, though: why 0xC0000004 and not 0xC0000000 as
> > 0xC0000004 is because hpux uses it (;
> Actually, I meant ``why does HP-UX use that address?''. =)
my guess is NULL-challenge (:

> > dunno about linux's binary emulation principles, but for
> > all bsd's the emulation parameters pointer is located in the proc
> > structure, which allows syscall emulation to work even all
> > the emulated os'es are using the same syscall entry point (on some
> > architectures there might be only one possible way for syscall, 4 xampl)
> 
> Yes, we can do that too (and do on SPARC for Solaris at least, perhaps
> SunOS as well), but it seems less efficient than just using different
> syscall numbers or -- in the case of lovely hardware like PA-RISC --
> using a different gateway address.
ok, valid.
let's think what is less efficient: extra mapped page, or
extra indirrect ptr reference?
my point is, why map extra page (and waiste extra page) ?
one page is 128 page dir entries, hehe (; returning to the pd discussion)

> > > 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?)
> > there is no such pa-risc instruction like ldi, it's a pseudo-asm-insn
> > which is actually ldo imm(0), rt
> > the whole pa-risc asm is full of pseudo-insns (like comb, comib, b(ranch))
> 
> That I know, but ``ldo 5,%r22'' is illegal syntax (according to gas and
> the assembler reference, anyway), and that's what appears in the
> Assembler Ref.
ah, oh, that's too bad.
i guess i've made the typo/reado as they did in the manual (:
(btw, 'i' and 'o' are very close on the kbd ;)

cu

-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Re: [hppa-linux] syscall work

[Stan Sieler]

Re:

> let's think what is less efficient: extra mapped page, or
> extra indirrect ptr reference?
> my point is, why map extra page (and waiste extra page) ?
> one page is 128 page dir entries, hehe (; returning to the pd discussion)

If you're talking about the gateway page, if you don't actually *allocate*
a page, but simply rely on the trap that occurs when you try to jump to it,
then there's 0 storage cost for the extra mapped page approach...no TLB
entry, no entries in other data structures.  The only cost is the
additional CPU time in the TLB miss handler to say:

   if isr.ior = 0xc0000400 (or whatever)
      then handle system call attempt
   else
      handle TLB miss

BTW, the extra cost of doing a system call mechanism via a non-mapped gateway page
vs. using a GATE instruction is about 5 microseconds on a 32MHz machine.
 
-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: [hppa-linux] syscall work

[Michael Shalayeff]

re
okie, but why emulating gate instruction, when there is already such
instruction exist? (;
page w/ gate instructions needed for existing (3 already) operating systems
compatibility, so it's needed anyway, and btw having the gateway
page mapped (and only one) could result in that it's tlb mapping would
persist in the tlb improving perfomance, while doing if() would
always penilize. this needs actual measurement, but i beleive certain
cases w/ many syscalls being called should be very possible.
cu

Making, drinking tea and reading an opus magnum from Stan Sieler:
> Re:
> 
> > let's think what is less efficient: extra mapped page, or
> > extra indirrect ptr reference?
> > my point is, why map extra page (and waiste extra page) ?
> > one page is 128 page dir entries, hehe (; returning to the pd discussion)
> 
> If you're talking about the gateway page, if you don't actually *allocate*
> a page, but simply rely on the trap that occurs when you try to jump to it,
> then there's 0 storage cost for the extra mapped page approach...no TLB
> entry, no entries in other data structures.  The only cost is the
> additional CPU time in the TLB miss handler to say:
> 
>    if isr.ior = 0xc0000400 (or whatever)
>       then handle system call attempt
>    else
>       handle TLB miss
> 
> BTW, the extra cost of doing a system call mechanism via a non-mapped gateway page
> vs. using a GATE instruction is about 5 microseconds on a 32MHz machine.
>  
> -- 
> Stan Sieler                                          sieler@allegro.com
>                                      http://www.allegro.com/sieler.html
> 
> 


-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Re: [hppa-linux] syscall work

[Michael Shalayeff]

Making, drinking tea and reading an opus magnum from Stan Sieler:
> Hi,
re

> > okie, but why emulating gate instruction, when there is already such
> > instruction exist? (;
> 
> Simple: HP does this...there must be a reason.
> 
> They appear to do it on selected models of PA-RISC systems.  Why?  Don't know.
which models? could it be level 1 systems w/ less VM resources?

> I can only conjecture...and the conjecture is the obvious one: there must be
> some circumstance where GATE fails.  Otherwise, *why* replace it with
> a slightly slower mechanism?
hardware bug for example? maybe again on certain systems w/ less
tlb size and/or cache.

btw, lites/mklinux do not emulate gate.

cu


-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Re: [hppa-linux] syscall work

[Stan Sieler]

Hi,

> okie, but why emulating gate instruction, when there is already such
> instruction exist? (;

Simple: HP does this...there must be a reason.

They appear to do it on selected models of PA-RISC systems.  Why?  Don't know.

I can only conjecture...and the conjecture is the obvious one: there must be
some circumstance where GATE fails.  Otherwise, *why* replace it with
a slightly slower mechanism?

-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: [hppa-linux] syscall work

[Bjorn Helgaas]

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

Re: [hppa-linux] syscall work

[Alan Cox]

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

Re: [hppa-linux] syscall work

[Cary Coutant]

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

Re: [hppa-linux] syscall work

[Mike Shaver]

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

Re: [hppa-linux] syscall work

[Alan Cox]

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

[hppa-linux] syscall work

[Mike Shaver]

[-- 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);                                                     \
}