linux-mips
[Top] [All Lists]

Re: R10K speculative store on non-coherent systems workaround proposal

To: Ralf Baechle <ralf@uni-koblenz.de>
Subject: Re: R10K speculative store on non-coherent systems workaround proposal
From: Vivien Chappelier <vivien.chappelier@enst-bretagne.fr>
Date: Fri, 14 Jun 2002 01:17:44 +0200 (CEST)
Cc: linux-mips@oss.sgi.com
In-reply-to: <1023707152.18634.18.camel@dea.linux-mips.net>
Sender: owner-linux-mips@oss.sgi.com
On 10 Jun 2002, Ralf Baechle wrote:

> Looks like a good start but unfortunately your concept is ignoring
> userspace entirely.

indeed ;)

> You might have to deal with mmapped pages that are being written to
> backing storage.

True.

> In such a case you'll have to trackdown all mappings and disable
> access to them

I don't think so. Before doing DMA, pages will be locked with lock_page
(mm/filemap.c) and processes accessing this page will be
forced to wait for I/O completion. Quote from include/asm/page.h:
>> * During disk I/O, PG_locked is used. This bit is set before I/O
>> * and reset when I/O completes. page->wait is a wait queue of all
>> * tasks waiting for the I/O on this page to complete.

Thus, no user process should be accessing the page during the I/O transfer
(this would cause problems anyway, even on coherent
architectures). However, now our problem is that the mappings may still be
in the TLB, and thus speculative stores could be executed to the DMA
buffer. However, this can be easily worked around by flushing the TLB
entries for these mappings (we only have 64 to check, or we can do the
bovine flush_tlb_all ;)). Thus mappings will be invalid for the CPU,
causing an exception that will abort the speculative store.
Does that sound ok?

> Intially I guess you can simply avoid this hairy job by doing all DMA using
> bounce buffers only.  Expensive but doable ...

I'd prefer to avoid those expensive memcpy if possible..

Vivien.


<Prev in Thread] Current Thread [Next in Thread>