Re: [parisc-linux] Linux syscall ABI

[Philipp Rumpf <prumpf@inwestnet.de>]

> > > But Perhaps we can have a 16 Mb offset instead.
> >
> > I think not mapping the first 64 KB and making a copy of page 0 somewhere
> > else would make sense.  Then we could use the first 64 KB of the virtual
> > address space to implement gateway pages.
> 
> We can probably use a smaller offset than 16 Mb but 64 Kb won't work.  We

I didn't propose any offset.  I proposed to do the mapping somewhat like this:

virt		phys
0000 0000 	somewhere (whereever our syscall page is)
0000 1000 	- (invalid)
 ...
0000 f000	- (invalid)
0001 0000 	0001 0000
 ...
01ff f000	01ff f000

for a 32 MB box.  This is why I said we should make a copy of page 0.

> Rereading what you said above made me realize that you probably were not
> talking about a 64 Kb offset. If so, then you are talking about
> still using an offset of 0, but just not mapping the first 64 Kb a memory,
> i.e. throwing those pages "away" (actually we can probably find ways
> to use them). The only problem with this is that we would be prevented
> from using maximally large tlb mappings to map the first 64 Mb of memory.

I don't think I care.  Note that this is for PA1.1 anyway, so we don't have
large pages architecturally.

> If we moved the offset to 64 Mb we could use 64 Mb page size mappings
> to map the kernel address space. The cost of this is that it reduces
> the amount of physical memory we can support.  We can't support 4 Gb
> (at least not easily), since we need virtual space for the vmalloc area.
> So I'm not sure losing 64 Mb of virtual space at the bottom end is that
> much of an issue.
> 
> What is the largest amount of physical memory we want to support for the
> 32 bit implementation?  How hard do we want to work to achieve it?  We
> can't support more than 4 Gb.  It would take some work to support 4 Gb.
> My feeling is that if we supported 3.5 Gb max that would be more than
> adequate.  We could use a 64 Mb offset and use 64 Mb page size mappings to
> cover the kernel address space.  This should leave enough space for the
> vmalloc area.

IMHO, don't map the first 64 KB, map the first 3.25 GB - 64 KB, then have
512 MB vmalloc space, then 256 MB I/O space.  (For newer boxes it looks like
the 64 KB we don't map should be more like 1 MB).

> > I don't see a real problem with that.  Modifying SR2 requires either direct
> > modification (the only code I could see doing that is HP/UX code, which isn't
> > supposed to execute with PER_LINUX anytime soon) or executing random bytes,
> > which will always break in unexpected ways.
> >
> 
> I agree that it is not a significant enough problem to stop us from doing
> this. So, I propose the following:
> 
>     1) When we move the kernel virtual mappings we will leave room at
>     the bottom to a) properly trap on null pointer dereferences, and
>     b) provide room for a Linux syscall gateway page in the kernel
>     address space (space 0). This gateway page will be located at an
>     offset within the positive offset range of a ble instruction.

If you mean "not map the first 64 KB - 1 MB" by "leave room", I agree.

>     2) We will set sr2 to zero for each process.

Agreed.

>     3) We will only map an HP-UX syscall gateway page into HP-UX
>     processes, i.e. we will not map any gateway page into the user
>     address space for PER_LINUX processes.

agreed.

>     4) Linux syscalls will use the following 2 instruction sequence
>     to reach the gateway page:
> 
> 	ble <gateway offset>)(%sr2,%r0)
> 	ldi <syscall #>,%r20

I'd prefer to fix gateway offset now - it's a pretty arbitrary decision,
but it might break binary compatibility lateron.  My proposal is 0x100.

So did anyone think about how to write the actual syscall asm statements ?
it seems rather hard to me, at least without writing the actual functions
directly and having one more level of indirection ...