Path: utzoo!attcan!uunet!husc6!im4u!ut-sally!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: virtual I/O
Summary: useful gains (and looking at the pdp-11 again)
Message-ID: <5348@ico.ISC.COM>
Date: 23 May 88 23:24:53 GMT
References: <1605@pt.cs.cmu.edu> <28200142@urbsdc>, <3033@encore.UUCP> <1988May12.164906.17159@utzoo.uucp>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 48

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