Re: TSS switching

[Roland McGrath]

> I don't know yet enough.  It's okay to not fix the broken code and put the
> new implementation there immediately, but I would like to have at least an
> idea why the code doesn't work "as is".

I won't discourage you from working on it.  But I've always found debugging
this stuff to be pretty aggravating.

> BTW, can we avoid copying the bitmap if we switch from one thread to another
> thread in the same task?

Of course.  That's what I meant when I described how to make it task-based.
Look at the places switch_ktss is called.  Right before that, is the pmap
switching done only if the task is changing; we'd do the io bitmap there too.

> Or, a related question, when does a change in the bitmap become
> effective, immediately or at the next switch to the thread?  This is a
> part of the current implementation I don't see.  Linux simply diddles the
> task (thread?! [1]) bitmap and the kernel tss at the same time.

In the current implementation, it diddles them at the same time
too--because they are both the same memory.  The only place a bitmap is
stored is in the io_tss.  If the current thread is the one being diddled,
that io_tss is the memory that the USER_TSS segment points at.

What is really tricky is how the newly-allocated tss gets switched to when
the current thread is the one getting a bitmap for the first time.  You
don't see it happen in iopb.c because it doesn't!  If there is a context
switch to another thread and back to that one, then it will be set.  But if
there is no context switch before the first io instruction that thread
tries, that instruction will trap.  Then it gets to emulate_io, which calls
switch_ktss.  (This is also where the insane automatic io access if your
task has some send right feature is implemented.)  However, it doesn't look
like emulate_io will actually dtrt if you don't have the iopl device port,
but almost.

There is no reason for it to be that way.  It ought to do switch_ktss
after allocating a new io_tss for the current thread.