9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
Subject: Re: [9fans] Raspberry Pi 4
Date: Thu, 25 Jul 2019 13:19:32 +0200	[thread overview]
Message-ID: <BB93560F2D01BD14E5D6511F61088E49@felloff.net> (raw)
In-Reply-To: 78df3ccd94cc441e3047a7698e43398b@hamnavoe.com

> Your dmaflush code doesn't look to me like it will do the right
> thing if the dma buffer isn't cache aligned.  (Could this ever be
> the case in the 9front kernel?) Suppose dma starts, cpu prefetches
> some old data into the cache line overlapping the start of the dma
> buffer, then dma completes.

> Your dmaflush then calls cachedwbse which writes back the pre-fetched
> data, overwriting the new data which dma wrote to memory.

what? where? it should call dmaflush with the clean parameter set
to zero after the hardware has completed the dma:

dma.c:228: 		dmaflush(0, ctlr->flush, ctlr->len);

dmaflush() then calls cachedwbinvse() on the partial cache lines
which should just invalidate IFF the lines are clean. the write back should
only happen when the lines are dirty. in that case the damage has already
been done and the wb at least makes sure we wont loose the dirty data
from the cache.

so the underlying assumption here is that a cache clean operation
writes back only when the line is dirty. correct me if i'm wrong
here.

so yes, it will not work correctly for an invalidate when the buffer
is not cache line size aligned and the partial start or end gets
modified while the dma operation is in flight.

--
cinap



             reply	other threads:[~2019-07-25 11:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 11:19 cinap_lenrek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-09-25 20:58 Richard Miller
2019-09-29 20:32 ` David du Colombier
2019-08-25 11:09 Richard Miller
2019-07-25 11:41 cinap_lenrek
2019-07-25  9:35 cinap_lenrek
2019-07-25 10:02 ` Richard Miller
2019-07-25 10:04   ` Richard Miller
2019-07-25  7:37 cinap_lenrek
2019-07-25  9:15 ` Richard Miller
2019-07-18 13:32 Richard Miller
2019-07-19  9:19 ` hiro
2019-07-19  9:41   ` Richard Miller
2019-07-19  9:45     ` hiro
2019-07-19  9:49       ` Richard Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BB93560F2D01BD14E5D6511F61088E49@felloff.net \
    --to=cinap_lenrek@felloff.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).