Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: virtual I/O
Message-ID: <1988May12.164906.17159@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1605@pt.cs.cmu.edu> <28200142@urbsdc>, <3033@encore.UUCP>
Date: Thu, 12 May 88 16:49:06 GMT

>Which brings up the question, why don't we do IO with virtual addresses? 
>We have living proof that it can be done. Why isn't it catching on?

Depends on what you mean by "catching on".  All Suns do IO with virtual
addresses -- there is no way to bypass the Sun MMU.  (Actually, I should
hedge that:  I know this applies to the Sun 3, but I might be wrong about
the others.)

> ... For a device that can potentially
> support concurrent traffic for more than one process, you need an MMU for
> each thread of control, and suddenly you have an allocation problem.

No, you just give the IO its own address space, and map pieces of the user
spaces into it.  I agree it's a bit less elegant than just handing the IO
device the whole user space.

> The other thing that consistently gets in the way is that IO has this tendency
> to require deterministic delays so various buffers don't overrun and the like.
> MMUs dont lend themselves well to that.

Some MMUs don't.  Some do.  Some of the ones that don't can be made to give
deterministic delays if the software makes a real effort.

> IO also doesn't know what to do with a fault.  

So you have to make sure it doesn't get any.  Again, a nuisance for the
software, but not a disaster.
-- 
NASA is to spaceflight as            |  Henry Spencer @ U of Toronto Zoology
the Post Office is to mail.          | {ihnp4,decvax,uunet!mnetor}!utzoo!henry