Re: Potential problem with the page_mapping macro and flush_dcache_page()

["David S. Miller" <davem@davemloft.net>]

From: James Bottomley <James.Bottomley@SteelEye.com>
Date: Sun, 19 Mar 2006 15:29:43 -0600

> On Sun, 2006-03-19 at 13:25 -0800, David S. Miller wrote:
> > This is exactly what Sparc64's caches are too, L1 D-cache is virtually
> > indexed and physically tagged.  But any bus coherency transaction will
> > update all lines with matching physical tags, otherwise things just
> > won't work.
> 
> I'm afraid ours don't.  The reason is that parisc caches are huge
> (around a megabyte), so you have to specify a coherence index (which is
> effectively the virtual index) to the IOMMU on DMA transactions and
> that's the only line it flushes (as long as the physical tags match).

I don't dispute how the parisc cache behaves, you know that better
than me, but I do want to know what in the world does the size of the
cache have to do with deciding whether to design the hardware to flush
all the matching lines or not?

It's a CAM lookup on bus snoop.  That can search all physical tags in
one CAM cycle, which will thus set the invalid bit on all matching
cache lines regardless of virtual index.

How is a virtual address getting into this equation at all?  The IOMMU
sits on some other bus agent such as the PCI controller, right?  So
coherency transactions, even if translated by the IOMMU from a PCI bus
virtual address to a physical main memory address, looks like a
physical address cache transation to the cpu caches on a bus snoop.

What am I missing?