>The problem I see with allowing the user-mode VM86 task to have a different
>sized bitmap from other tasks is that the bitmap is in the middle of the
>thread_struct and so all references to, e.g., tss -> tr depend on the
>bitmap having a fixed size. Not having the Intel docs in front of me
>at the moment I can't remember whether that is enforced by the processor
>but I suspect that it is.
I appear to have been wrong about that. The tss->bitmap value contains a
pointer to the start of the IO bitmap relative to the start of the TSS.
So in theory the bitmap could be moved to the end of the TSS and made
to be of variable size; the code which will need changing, apart from the
definition of thread_struct, is...
- the ioperm() code
- the fork code in process.c which initialises the bitmap
- the macro set_tss_desc and any code which uses it.
If the IO bitmap is created with a default size then you might get away
with not changing the code which allocates space for the thread_struct.
The IO bitmap size will need to be stored somewhere - add an extra element
to the thread_struct. I guess what will happen is if ioperm() is called
with ports which are not covered by the bitmap it allocates a larger TSS.
After doing that I guess it will need to cause a task switch.
imc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html