[coyotos-dev] syscall/sysret vs. small spaces

[Espen Skoglund]

[Jonathan S Shapiro]
>> And since our syscall page is not at a fixed location we don't want
>> to put them together.

> It is not obvious (to me) that the syscall page should not be at a
> fixed virtual location. Why not simply let it be a user-accessable
> page that appears within the kernel-owned portion of the virtual
> range?

> I think either design will work. I am simply curious whether you
> feel strongly about position independence here.

Because the page will not be accessible from small spaces (I'm
assuming the kernel resides in the upper part of virtual memory space
here).  Further, we want the system to be able to configure the layout
of the virtual memory area of the applications.  Having the page
mapped into a location in the lower part of memory prevents this.  Of
course, this might be acceptable in Coyotos.  I'm just saying that we
chose the non-fixed approach in L4 because it gives more flexibility
to the system on top.

>>> Hmm. I suppose that we could use a segment in the GDT to identify
>>> the sysexit path, which would permit the small space to execute an
>>> LCALL or LJMP into the syscall trampoline page. I had not
>>> considered that option before.
>> 
>> Yes, that would indeed be possible.  Don't know what the added cost
>> is, though.  Another question: Is it possible for standard program
>> linkers to also rewrite LCALL instructions?

> I believe that this can be relocated, but it doesn't really need to
> be, because the segment-relative offset can be fixed at design
> time. My sense is that LJMP/LCALL is more expensive than JMP/CALL,
> but probable no more expensive than the PLT transfer conventions
> that are needed to support a position-independent syscall
> trampoline. I'm not certain -- this would need measurement.

If you have only a single syscall entry then a hardcoded value is
probably ok.  In L4 we have one entry point for every syscall and we
don't want to limit code layout, etc., in the syscall page by having
the entry points at fixed locations.

> [...]

> Another possibility, of course, is to declare for Coyotos that
> SYSENTER is the approved IA32 syscall mechanism, and hard-code the
> entry path into the stubs generated by the IPC compiler. That is,
> eliminate the syscall trampoline page but leave the sysexit
> trampoline as you describe.

> I am a little reluctant to do this, mainly because we know that
> SYSENTER/SYSEXIT has been gotten wrong before...

It also prevents you from using future (or existing) more efficient
alternatives for entering the kernel (don't know if AMD's
syscall/sysret is faster on their CPUs).  In some cases you might even
perform the syscall without entering the kernel at all.

	eSk