Re: I/O flexpages / new mapping DB issue with overlapping ports

[Frank Mehnert]
> Espen,
> thank you very much for fixing these issues, I will test it as soon
> I can update my CVS.

> Another related question comes up: Since the kernel allows Sigma0 to
> map every I/O flexpage the responsibility lies at the privileged
> tasks to prevent mapping of I/O ports the kernel uses itself. I
> assume the same applies to MSRs. However, neither Sigma0 nor root
> task have any information about the I/O ports and MSRs the kernel is
> using.

No, you're right.  The user-level servers have no way to know which IO
ports are used by the kernel.  The kernel could of course just block
all accesses to IO ports it used (e.g., for the interrupt controller).
For other IO ports like the serial port used for the kernel debugger,
it could stop using these ports once it detects that some user-level
server starts using them.

For MSRs the current solution is that the priviliged servers can
access all MSRs.  The kernel does not guarantee no bad side effects by
doing so.  And as with the IO ports, the user-level servers have no
way to tell which MSRs are used by the kernel.

There was at some stage some loose talk about implementing an MSR
space with similar semantics as the IO space.  This is quite trivial
to do using the current code base in Pistachio.  Whether there are any
real benefits to doing so is a different question.

	eSk