Re: SF Ballot Counting Keyhole; call for non-GUI keyholes

Fedor Pikus <[email protected]> Sat, 6 Nov 2004 22:45:12 -0800 (PST)
Newsgroups gmane.comp.programming.keyholes
Message-ID <Pine.LNX.4.61.0411062220030.4759@lorien>
Here is a nice juicy one (non-GUI). Actually, more than one lumped 
together. Takes a bit of an introduction though:
When AMD came out with 64-bit CPUs, one of the things they realized was 
that there are loads of I/O cards which do DMA (direct memory access) for 
their memory transfers (all video cards do, all disk controllers, most 
network cards, etc), but most of these cards will have 32-bit DMA because 
they were designed before a 64-bit PC existed. Rather than requiring all 
new hardware for their CPUs, they implemented a hardware solution called 
I/O Memory Mapping Unit (IOMMU) which remaps 32-bit DMA accesses onto 
64-bit address space. So far so good.

Now enter Intel, who just sunk untold gazillion $$$s into Itanic and needs 
a working 64-bit CPU fast. They do a quick and dirty job of cloning the 
Opteron and produce Nocona, but leave out few things here and there, IOMMU 
being one of them. This throws the problem into the lap of OS writers, 
who have to implement a software remapping.

Cue in the Linux kernel. It had for quite a while an obscure feature that 
nobody cared about called Software IO Translation Buffer (SWIOTLB). 
Suddenly this feature is front and center as Noconas appear on the market.
The buffer must be allcoated in low memory (which is the only one DMA can 
reliably access), which means it's allocated early at boot time, before 
kernel has to start doling out memory. Once allocated, it cannot be reused 
for anything else (because there is no way to grow it back). How much 
buffer you need? Depends on how much memory is on the video card and how 
much main memory it will try to access through DMA. In other words, the 
kernel has no idea how much. It allocates some. What happens if the video 
card overruns the SWIOTLB? Two things: kernel panics, and a random address 
is returned to the program which requested the allocation (so just in case 
you can survive the kernel being yanked from under you you can't get too 
far, I guess).

As a user, you know how much memory your video card has, and indeed the 
kernel provides an option to specify SWIOTLB size at boot. So, if you are 
building a nice gaming PC, you plug in a GeForce 6800 with 256MB of 
memory, and suddenly you need to allocate half a gig for SWIOTLB. I guess 
we won't be seeing many gaming or 3D graphics PCs with Noconas.

So we have a similar scenario where an obscure keyhole nobody cared about 
suddenly became a major keyhole, on top of the keyhole created by Intel's 
limited implementation of DMA.

Fedor

On Sat, 6 Nov 2004, Scott Meyers wrote:
> In the meantime, if you come across non-GUI keyhole examples of the kind
> suggested above, please send them to me or post them to this mailing list.
> I continue to believe that GUI keyholes are just a manifestation of a more
> widespread conceptual problem, but additional examples will help me make
> the case more successfully.
>
> Thanks,
>
> Scott

-- 
                                   Fedor G. Pikus
Mentor Graphics Corporation         | Phone: (503) 685-4857
8405 SW Boeckman Road               | FAX:   (503) 685-1239
Wilsonville, Oregon 97070           | http://www.pikus.net/~pikus/