From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 6/7] xen/arm: flush D-cache and I-cache when appropriate
Date: Sat, 27 Oct 2012 11:44:28 +0100 [thread overview]
Message-ID: <20121027104428.GB89901@ocelot.phlegethon.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1210261937180.2689@kaball.uk.xensource.com>
At 19:40 +0100 on 26 Oct (1351280413), Stefano Stabellini wrote:
> > No! It's always safe to flush the entire line -- regardless of what
> > other writes might be happening to it. After all, the cache controller
> > might evict that line on its own at any time, so nothing can be relying
> > on its _not_ being flushed.
> >
> > The only problem with not knowing how big a cacheline is is this: if the
> > object is _bigger_ than a cache line we might use one DCCMVAC where more
> > than one is needed. We can avoid that by a compile-time check on some
> > sort of architectural minimum cacheline size.
>
> If we want to do that then we need to pass a size argument to
> flush_xen_dcache_va and have a loop in the function, each iteration
> flushing a cacheline:
>
> static inline void flush_xen_dcache_va(void *p, unsigned long size)
> {
> unsigned long cacheline_size = READ_CP32(CCSIDR);
> unsigned long i;
> for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
> asm volatile (
> "dsb;"
> STORE_CP32(0, DCCMVAC)
> "dsb;"
> : : "r" (p));
> }
> }
I think we should have two functions. One should look almost like that
and be for flushing large ranges, and one much simpler for flushing
small items. Like this (totally untested, uncompiled even):
#define MIN_CACHELINE_BYTES 32 // or whatever
/* In setup.c somewhere. */
if ( READ_CP32(CCSIDR) < MIN_CACHELINE_BYTES )
panic("CPU has preposterously small cache lines");
/* Function for flushing medium-sized areas.
* if 'range' is large enough we might want to use model-specific
* full-cache flushes. */
static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
{
void *end;
unsigned long cacheline_bytes = READ_CP32(CCSIDR);
barrier(); /* So the compiler issues all writes to the range */
dsb(); /* So the CPU issues all writes to the range */
for ( end = p + size; p < end; p += cacheline_bytes )
WRITE_CP32(DCCMVAC, p);
dsb(); /* So we know the flushes happen before continuing */
}
/* Macro for flushing a single small item. The predicate is always
* compile-time constant so this will compile down to 3 instructions in
* the common case. Make sure to call it with the correct type of
* pointer! */
#define flush_xen_dcache_va(p) do { \
typeof(p) _p = (p); \
if ( (sizeof *_p) > MIN_CACHELINE_BYTES ) \
flush_xen_dcache_va_range(_p, sizeof *_p); \
else \
asm volatile ( \
"dsb;" /* Finish all earlier writes */ \
STORE_CP32(0, DCCMVAC) \
"dsb;" /* Finish flush before continuing */ \
: : "r" (_p), "m" (*_p)); \
} while (0)
What do you think?
Tim.
next prev parent reply other threads:[~2012-10-27 10:44 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 15:03 [PATCH 0/7] xen/arm: run on real hardware Stefano Stabellini
2012-10-24 15:03 ` [PATCH 1/7] xen/arm: fix rank calculation in vgic_vcpu_inject_irq Stefano Stabellini
2012-10-25 9:27 ` Ian Campbell
2012-10-26 16:33 ` Stefano Stabellini
2012-10-26 16:40 ` Ian Campbell
2012-10-26 18:42 ` Stefano Stabellini
2012-10-26 20:47 ` Ian Campbell
2012-10-27 10:09 ` Tim Deegan
2012-10-27 10:44 ` Ian Campbell
2012-11-13 11:57 ` Stefano Stabellini
2012-11-13 12:00 ` Ian Campbell
2012-11-13 12:23 ` Stefano Stabellini
2012-10-24 15:03 ` [PATCH 2/7] xen/arm: setup the fixmap in head.S Stefano Stabellini
2012-10-24 15:27 ` Tim Deegan
2012-10-24 15:37 ` Stefano Stabellini
2012-10-25 9:33 ` Ian Campbell
2012-10-25 11:00 ` Stefano Stabellini
2012-10-24 15:03 ` [PATCH 3/7] pl011: set baud and clock_hz to the right defaults for Versatile Express Stefano Stabellini
2012-10-25 9:37 ` Ian Campbell
2012-10-25 10:57 ` Stefano Stabellini
2012-10-25 11:00 ` Ian Campbell
2012-10-24 15:03 ` [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR register Stefano Stabellini
2012-10-25 9:52 ` Ian Campbell
2012-10-25 11:57 ` Stefano Stabellini
2012-10-25 12:04 ` Ian Campbell
2012-10-26 8:56 ` Tim Deegan
2012-10-26 8:59 ` Ian Campbell
2012-10-24 15:03 ` [PATCH 5/7] xen/arm: wake up secondary cpus Stefano Stabellini
2012-10-24 15:38 ` Tim Deegan
2012-10-24 15:59 ` Stefano Stabellini
2012-10-24 16:05 ` Tim Deegan
2012-10-25 9:59 ` Ian Campbell
2012-10-25 17:45 ` Stefano Stabellini
2012-10-26 7:30 ` Ian Campbell
2012-10-26 11:18 ` Stefano Stabellini
2012-10-26 12:16 ` Ian Campbell
2012-10-26 15:24 ` Stefano Stabellini
2012-10-26 15:32 ` Ian Campbell
2012-10-24 15:03 ` [PATCH 6/7] xen/arm: flush D-cache and I-cache when appropriate Stefano Stabellini
2012-10-24 15:59 ` Tim Deegan
2012-10-24 16:05 ` Ian Campbell
2012-10-24 16:17 ` Tim Deegan
2012-10-24 17:35 ` Stefano Stabellini
2012-10-26 9:01 ` Tim Deegan
2012-10-26 15:53 ` Stefano Stabellini
2012-10-26 15:55 ` Stefano Stabellini
2012-10-26 16:03 ` Stefano Stabellini
2012-10-26 16:55 ` Tim Deegan
2012-10-26 18:40 ` Stefano Stabellini
2012-10-27 10:44 ` Tim Deegan [this message]
2012-10-27 11:54 ` Tim Deegan
2012-10-29 9:53 ` Stefano Stabellini
2012-10-29 9:52 ` Stefano Stabellini
2012-11-13 12:01 ` Stefano Stabellini
2012-11-13 12:15 ` Tim Deegan
2012-10-26 16:45 ` Tim Deegan
2012-10-24 15:03 ` [PATCH 7/7] xen/arm: get the number of cpus from device tree Stefano Stabellini
2012-10-25 10:02 ` Ian Campbell
2012-10-24 16:02 ` [PATCH 0/7] xen/arm: run on real hardware Tim Deegan
-- strict thread matches above, loose matches on Subject: below --
2012-11-13 15:40 [PATCH v2 " Stefano Stabellini
2012-11-13 15:42 ` [PATCH 6/7] xen/arm: flush D-cache and I-cache when appropriate Stefano Stabellini
2012-11-15 10:02 ` Ian Campbell
2012-11-16 15:36 ` Stefano Stabellini
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=20121027104428.GB89901@ocelot.phlegethon.org \
--to=tim@xen.org \
--cc=Ian.Campbell@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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).