[comp.arch] virtual I/O

henry@utzoo.uucp (Henry Spencer) (05/12/88)

>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

rcd@ico.ISC.COM (Dick Dunn) (05/24/88)

> >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...

The PDP-11 had the capability to do virtual I/O after a fashion.  It was
used in the case of UNIX "raw" I/O, which is intended as a direct transfer
between device and a user process address space.

> > ...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...

This may or may not give you an "allocation problem" (depending on what
that means).  A problem mentioned in the grandparent article was that I/O
devices don't want to wait while you reload a TLB from disk--they may have
serious timing constraints.  You can get around this by having the
translation tables for I/O be locked down (or even special hardware)--in
which case you don't have a delay problem but the hardware may be limited
in size to the point where you have an allocation "problem".  It's actually
not a problem, just some code that has to be written to manage the
allocation.

The 11 has an animal called the "UNIBUS map".  Part of the physical address
space on the 11s is arranged so that accesses to it are caught and the
upper bits are translated by a hardware table.  A device driver which is
going to do "raw" I/O will allocate entries from this map and set them to
point into user space, do the I/O into the "physical" area covered by that
part of the map, and deallocate the entries.  Naturally, the actual user
memory needs to be locked down during the transfer.

- - - - -

The lack of virtual I/O capability can be a real killer for raw I/O in some
cases.  If you're transferring data to/from a disk controller that doesn't
have scatter/gather capability, you end up making one of two rather
unpleasant choices:
	User buffers must be page-aligned.
			or
	You may end up copying raw I/O through kernel buffers.
The problem is that virtually contiguous addresses may not be physically
contiguous.  If you have to transfer to physical addresses and you can't
scatter a read, you have to do the transfer to contiguous memory and
transfer it.
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...If you get confused just listen to the music play...

henry@utzoo.uucp (Henry Spencer) (05/29/88)

> The 11 has an animal called the "UNIBUS map"...

Dept of Picky Corrections:  *some* 11s have a Unibus map.  Basically it's
the ones that have memory addresses bigger than 18 bits, which excludes a
lot of the early ones and the small ones.
-- 
"For perfect safety... sit on a fence|  Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry