From: Andrew Morton <akpm@linux-foundation.org>
To: steiner@sgi.com
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de,
holt@sgi.com, andrea@qumranet.com
Subject: Re: [patch 01/11] GRU Driver - hardware data structures
Date: Mon, 9 Jun 2008 15:52:17 -0700 [thread overview]
Message-ID: <20080609155217.97806364.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080609211044.992972808@attica.americas.sgi.com>
On Mon, 09 Jun 2008 16:10:29 -0500
steiner@sgi.com wrote:
> This patch contains the definitions of the hardware GRU data structures that are used
> by the driver to manage the GRU.
>
oh goody, more code to review.
>
> ...
>
> +/* Convert resource counts to the number of AU */
> +#define GRU_DS_BYTES_TO_AU(n) (((n) + GRU_DSR_AU_BYTES - 1) / \
> + GRU_DSR_AU_BYTES)
> +#define GRU_CB_COUNT_TO_AU(n) (((n) + GRU_CBR_AU_SIZE - 1) / \
> + GRU_CBR_AU_SIZE)
These are open-coded ROUND_UP()s
> +/* UV limits */
> +#define GRU_CHIPLETS_PER_HUB 2
> +#define GRU_HUBS_PER_BLADE 1
> +#define GRU_CHIPLETS_PER_BLADE (GRU_HUBS_PER_BLADE * GRU_CHIPLETS_PER_HUB)
> +
> +/* User GRU Gseg offsets */
> +#define GRU_CB_BASE 0
> +#define GRU_CB_LIMIT (GRU_CB_BASE + GRU_HANDLE_STRIDE * GRU_NUM_CBE)
> +#define GRU_DS_BASE 0x20000
> +#define GRU_DS_LIMIT (GRU_DS_BASE + GRU_NUM_DSR_BYTES)
> +
> +/* General addressing macros. b=grubase, c=ctxnum, i=cbnum, cl=cacheline# */
> +#define GRU_GSEG(b, c) ((void *)((b) + GRU_GSEG0_BASE + \
> + GRU_GSEG_STRIDE * (c)))
> +#define GRU_GSEG_CB(b, c, i) ((void *)(GRU_GSEG((b), (c)) + \
> + GRU_CB_BASE + GRU_HANDLE_STRIDE * (i)))
> +#define GRU_GSEG_DS(b, c, cl) ((void *)(GRU_GSEG((b), (c)) + \
> + GRU_DS_BASE + GRU_CACHE_LINE_BYTES * (cl)))
> +#define GRU_TFM(b, c) ((struct gru_tlb_fault_map *) \
> + ((unsigned long)(b) + GRU_TFM_BASE + (c) * GRU_HANDLE_STRIDE))
> +#define GRU_TGH(b, c) ((struct gru_tlb_global_handle *) \
> + ((unsigned long)(b) + GRU_TGH_BASE + (c) * GRU_HANDLE_STRIDE))
> +#define GRU_CBE(b, n) ((struct gru_control_block_extended *) \
> + ((unsigned long)(b) + GRU_CBE_BASE + (n) * GRU_HANDLE_STRIDE))
> +#define GRU_TFH(b, n) ((struct gru_tlb_fault_handle *) \
> + ((unsigned long)(b) + GRU_TFH_BASE + (n) * GRU_HANDLE_STRIDE))
> +#define GRU_CCH(b, n) ((struct gru_context_configuration_handle *) \
> + ((unsigned long)(b) + GRU_CCH_BASE + (n) * GRU_HANDLE_STRIDE))
> +#define GRU_GSH(b) ((struct gru_global_status_handle *) \
> + ((unsigned long)(b) + GRU_GSH_BASE))
Is there any particular reason why these had to be implemented via macros?
> +/*
> + * Test if an offset is a valid kernel handle address.
> + * Ex: TYPE_IS(CBE, chiplet_offset)
> + */
> +#define TYPE_IS(hn, h) ((h) >= GRU_##hn##_BASE && (h) < \
> + GRU_##hn##_BASE + GRU_NUM_##hn * GRU_HANDLE_STRIDE && \
> + (((h) & (GRU_HANDLE_STRIDE - 1)) == 0))
That one will misbehave if passed an `h' whcih hasside-effects. I
guess that's hard to fix if you need to retain the pasting thing.
> +/*
> + * Test a GRU physical address to determine the type of address range (does
> + * NOT validate holes)
> + */
> +#define IS_MCS_PADDR(h) (((h) & (GRU_SIZE - 1)) >= GRU_MCS_BASE)
> +#define IS_CBR_PADDR(h) (((h) & (GRU_SIZE - 1)) < \
> + GRU_MCS_BASE && (((h) & (GRU_GSEG_STRIDE - 1)) < GRU_DS_BASE))
has the same bug, but doesn't do pasting.
> +#define IS_DSR_PADDR(h) (((h) & (GRU_SIZE - 1)) < GRU_MCS_BASE && \
> + (((h) & (GRU_GSEG_STRIDE - 1)) >= GRU_DS_BASE))
ditto.
> +/* Convert an arbitrary handle address to the beginning of the GRU segment */
> +#ifndef __PLUGIN__
> +#define GRUBASE(h) ((void *)((unsigned long)(h) & ~(GRU_SIZE - 1)))
> +#else
> +/* Emulator hack */
> +extern void *gmu_grubase(void *h);
> +#define GRUBASE(h) gmu_grubase(h)
> +#endif
> +
> +/* Convert a GRU physical address to the chiplet offset */
> +#define GSEGPOFF(h) ((h) & (GRU_SIZE - 1))
> +
> +/* Convert a GSEG CB address to the relative CB number within the context */
> +#define CBNUM(cb) ((((unsigned long)(cb) - GRU_CB_BASE) % GRU_GSEG_PAGESIZE) / \
> + GRU_HANDLE_STRIDE)
> +
> +/* Convert a TFH address to the relative TFH number within the GRU*/
> +#define TFHNUM(tfh) ((((unsigned long)(tfh) - GRU_TFH_BASE) % GRU_SIZE) / \
> + GRU_HANDLE_STRIDE)
> +
> +/* Convert a CCH address to the relative context number within the GRU*/
> +#define CCHNUM(cch) ((((unsigned long)(cch) - GRU_CCH_BASE) % GRU_SIZE) / \
> + GRU_HANDLE_STRIDE)
> +
> +/* Convert a CBE address to the relative context number within the GRU*/
> +#define CBENUM(cbe) ((((unsigned long)(cbe) - GRU_CBE_BASE) % GRU_SIZE) / \
> + GRU_HANDLE_STRIDE)
> +
> +/* Convert a TFM address to the relative context number within the GRU*/
> +#define TFMNUM(tfm) ((((unsigned long)(tfm) - GRU_TFM_BASE) % GRU_SIZE) / \
> + GRU_HANDLE_STRIDE)
> +
> +/* byte offset to a specific GRU chiplet. (p=pnode, c=chiplet (0 or 1)*/
> +#define GRUCHIPOFFSET(p, c) (GRU_SIZE * ((p) * 2 + (c)))
etc.
> +#ifndef BITS_TO_LONGS
> +#define BITS_TO_LONGS(bits) (((bits)+64-1)/64)
> +#endif
BITS_TO_LONGS is defined in include/linux/bitops.h. Is this here just
for userspace inclusion? If not, it can go. If so, don't we have a
32-bit problem? Or does this code have the suitable 64-bit Kconfig
dependencies?
> +/*
> + * GSH - GRU Status Handle
> + * Shows status of each CBR/CBR resources
> + */
> +struct gru_global_status_handle {
> + unsigned long bits[BITS_TO_LONGS(GRU_NUM_CBE) * 2];
That's an open-coded DECLARE_BITMAP.
I'm assuming that we're about to see large amounts of code which
reimplements the functions which the bitmap library offers, so I'll
just ask: should this code be using the bitmap library?
> + unsigned int opc:1;
> + unsigned int fill1:5;
> +
> + unsigned int fill2:8;
> +
>
> ...
>
> +#ifdef __KERNEL__
> +#include "gru_instructions.h"
> +
> +/* Extract the status field from a kernel handle */
> +#define GET_MSEG_HANDLE_STATUS(h) (((*(unsigned long *)(h)) >> 16) & 3)
> +
> +#if defined __ia64__
> +#elif defined __x86_64__
> +#endif
CONFIG_IA64 and CONFIG_X86_64 would be more fashionable.
> +static inline void start_instruction(void *h)
> +static inline int wait_instruction_complete(void *h)
> +static inline void cch_allocate_set_asids(
> +static inline void cch_allocate_set_asids(
> +static inline int cch_allocate(struct gru_context_configuration_handle *cch,
> +static inline int cch_start(struct gru_context_configuration_handle *cch)
> +static inline int cch_interrupt(struct gru_context_configuration_handle *cch)
> +static inline int cch_deallocate(struct gru_context_configuration_handle *cch)
> +static inline int cch_interrupt_sync(struct gru_context_configuration_handle
> +static inline int tgh_invalidate(struct gru_tlb_global_handle *tgh,
> +static inline void tfh_write_only(struct gru_tlb_fault_handle *tfh,
> +static inline void tfh_write_restart(struct gru_tlb_fault_handle *tfh,
> +static inline void tfh_restart(struct gru_tlb_fault_handle *tfh)
> +static inline void tfh_user_polling_mode(struct gru_tlb_fault_handle *tfh)
> +static inline void tfh_exception(struct gru_tlb_fault_handle *tfh)
wow. Most of these are way too large to be inlined. And inlining is
so unweildy and namespace-polluty. How come?
next prev parent reply other threads:[~2008-06-09 22:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 21:10 [patch 00/11] GRU Driver steiner
2008-06-09 21:10 ` [patch 01/11] GRU Driver - hardware data structures steiner
2008-06-09 22:52 ` Andrew Morton [this message]
2008-06-10 4:07 ` Andi Kleen
2008-06-11 18:57 ` Jack Steiner
2008-06-09 21:10 ` [patch 02/11] GRU Driver - GRU instructions & macros steiner
2008-06-09 21:10 ` [patch 03/11] GRU Driver - driver internal header files steiner
2008-06-09 21:38 ` Roland Dreier
2008-06-10 14:57 ` Jack Steiner
2008-06-09 21:10 ` [patch 04/11] GRU Driver - kernel services " steiner
2008-06-09 21:10 ` [patch 05/11] GRU Driver - driver initialization, file & vma ops steiner
2008-06-09 21:10 ` [patch 06/11] GRU Driver - page faults & exceptions steiner
2008-06-09 21:10 ` [patch 07/11] GRU Driver - kernel services provide by driver steiner
2008-06-09 21:10 ` [patch 08/11] GRU Driver - resource management steiner
2008-06-09 21:10 ` [patch 09/11] GRU Driver - /proc interfaces steiner
2008-06-09 21:32 ` Roland Dreier
2008-06-09 22:11 ` Jack Steiner
2008-06-10 14:20 ` Roland Dreier
2008-06-09 21:10 ` [patch 10/11] GRU Driver - TLB flushing, MMUOPS callouts steiner
2008-06-09 21:10 ` [patch 11/11] GRU Driver - makefile & Kconfig file changes steiner
2008-06-09 21:35 ` Roland Dreier
2008-06-10 14:41 ` Jack Steiner
2008-06-12 13:27 ` [patch 00/11] GRU Driver Ingo Molnar
2008-06-12 14:05 ` Jack Steiner
2008-06-12 18:03 ` Andrew Morton
2008-06-12 20:52 ` Jack Steiner
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=20080609155217.97806364.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andrea@qumranet.com \
--cc=holt@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.