[PATCH 1/1] [V2] irqchip: gicv3-its: Introduce indirect device-ITT table support
Shanker Donthineni
shankerd at codeaurora.org
Tue Jan 26 16:50:51 PST 2016
Hi Marc,
On 01/26/2016 05:31 AM, Marc Zyngier wrote:
> Shanker,
>
> On 25/01/16 22:58, Shanker Donthineni wrote:
>> Current ITS driver implementation limits the device ID to a few
>> number of bits depending on memory that has been allocated to a
>> flat DEV-ITT table. Some of the devices are not usable when device
>> ID is spread out across a large range of 32 bit values.
> That's not really it. Indirect tables allow the system not to waste
> memory on very sparse tables (you could implement flat 32bit device ID
> tables by carving out memory out of the Linux managed memory).
I agree, I will change the commit text to reflect your comments in V3 patch.
>> This patch covers more DEVID bits by implementing the GIC-ITS indirect
>> device table. This feature is enabled automatically during driver
>> probe if the flat table is not adequate to hold all DEVID bits.
>>
>> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
>> ---
>> [v1]->[v2]:
>> -Removed the line "Change-Id: I9c6d005dexxx" from commit message.
>> -Fixed the its->max_devid field initialization.
>>
>> drivers/irqchip/irq-gic-v3-its.c | 79 +++++++++++++++++++++++++++++++++++---
>> include/linux/irqchip/arm-gic-v3.h | 1 +
>> 2 files changed, 75 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index e23d1d1..408a358 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -41,6 +41,8 @@
>>
>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>> +#define ITS_FLAGS_DEVICE_NEEDS_FLUSHING (1ULL << 2)
>> +#define ITS_FLAGS_INDIRECT_DEVICE_TABLE (1ULL << 3)
>>
>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>
>> @@ -71,6 +73,10 @@ struct its_node {
>> struct list_head its_device_list;
>> u64 flags;
>> u32 ite_size;
>> + u32 dev_table_idx;
>> + u32 dev_table_shift;
>> + u32 max_devid;
>> + u32 order;
> What are these new fields for?
These four fields are used for handling level-2 device table memory
allocation.
dev_table_idx - which array index in itx->tables[] holds level-one
device table.
order - page order of level-2 device table, reflects
size field (7..0) of GITS_BASER_DEVICE register.
dev_table_shift - contains the number of DEVID bits occupied by
level-2 device table.
max_devid - highest device id that can be supported by ITS
driver (will refactor to reflect your other comments below) .
>> };
>>
>> #define ITS_ITT_ALIGN SZ_256
>> @@ -824,6 +830,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>> u64 typer;
>> u32 ids;
>>
>> +#define ITS_DEVICE_MAX_ORDER min(MAX_ORDER, get_order(SZ_8M))
> Where is this 8MB value coming from?
Chose 8MB because It is an optimal value, It covers complete 32bit DEVID
space, with assumption device
table entry size is 8bytes and ITS hardware support 64K page size.
Example1 with ITS page size 64K + device table entry size 8bytes:
Level-1: ((page_order(8MB) – 1 ) * PAGE_SIZE) /level-one entry size =
4M/8 = 19bits
Level-2: 64K / 8 (device table entry size) = 13bits. (64K came from
default ITS page size)
with 8-Bytes device entry size = handles 32bit DEVID
with 16-Bytes device entry size = handles 31bit DEVID
with 32-Bytes device entry size = handles 30bit DEVID
Example2 with ITS page size 16K + device table entry size 8bytes:
Level-1: ((page_order(8MB) – 1 ) * PAGE_SIZE) /level-one entry size =
4M/8 = 19bits
Level-2: 16K / 8 (device table entry size) = 11bits. (for ITS hardware
that doesn't support 64K page size)
with 8-Bytes device entry size = handles 30bit DEVID
with 16-Bytes device entry size = handles 29bit DEVID
with 32-Bytes device entry size = handles 28bit DEVID
>> +
>> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_22375) {
>> /*
>> * erratum 22375: only alloc 8MB table size
>> @@ -867,11 +875,12 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>> */
>> order = max(get_order((1UL << ids) * entry_size),
>> order);
>> - if (order >= MAX_ORDER) {
>> - order = MAX_ORDER - 1;
>> - pr_warn("%s: Device Table too large, reduce its page order to %u\n",
>> - node_name, order);
>> - }
>> + if (order >= ITS_DEVICE_MAX_ORDER) {
>> + /* Update flags for two-level setup */
>> + its->flags |= ITS_FLAGS_INDIRECT_DEVICE_TABLE;
>> + order = ITS_DEVICE_MAX_ORDER - 1;
>> + } else
>> + its->max_devid = (1 << ids) - 1;
> We deal with the ID space in number of bits, not in number of devices we
> can represent. Yes, there is a direct relationship between the two, but
> I'd like to keep it consistent with the architecture specification.
I agree, will stick to ID space and add macro for conversion if need
after refactoring code.
>> }
>>
>> alloc_size = (1 << order) * PAGE_SIZE;
>> @@ -911,6 +920,26 @@ retry_baser:
>> break;
>> }
>>
>> + /* Enable two-level (indirect) device table if it is required */
>> + if ((type == GITS_BASER_TYPE_DEVICE) &&
>> + (its->flags & ITS_FLAGS_INDIRECT_DEVICE_TABLE)) {
>> + u32 shift = ilog2(psz / entry_size);
>> + u32 max_ids = ilog2(alloc_size >> 3) + shift;
> Please explain this calculation.
shift = number of LSB DEVID bits that are covered by level-2
page table.
i.e. (Level-2 device table size ) / (device table
entry size)
max_ids = level-1 device table size + shift (level-2 device table size)
i.e. (level-1 size) / level_1_entry_size (8) + shift
>> +
>> + if (ids > max_ids) {
>> + pr_warn(
>> + "ITS: @%pa DEVID too large reduce %u->%u\n",
>> + &its->phys_base, ids, max_ids);
>> + }
>> + its->max_devid = (1UL << max_ids) - 1;
>> + its->order = get_order(psz);
>> + its->dev_table_idx = i;
>> + its->dev_table_shift = shift;
>> + if (!(val & GITS_BASER_SHAREABILITY_MASK))
>> + its->flags |= ITS_FLAGS_DEVICE_NEEDS_FLUSHING;
> You can only evaluate the shareability after having written something,
> and read it back. Also, the name of the flag is a bit wrong: it is not
> the device that needs flushing, bit the ITS Device table.
there is a “goto retry_baser” statement at the end of “for loop” that
triggers above code logic that is repeated
whenever the ITS hardware doesn’t stick shareability bit.
>> + val |= GITS_BASER_INDIRECT;
> Erm... Do you realize that this is an optional feature? What happens if
> the HW doesn't support it?
I will refactor code to fix the issue in V3 patch.
>> + }
>> +
>> val |= alloc_pages - 1;
>>
>> writeq_relaxed(val, its->base + GITS_BASER + i * 8);
>> @@ -1134,6 +1163,32 @@ static struct its_device *its_find_device(struct its_node *its, u32 dev_id)
>> return its_dev;
>> }
>>
>> +static int its_alloc_device_table(struct its_node *its, u32 dev_id)
>> +{
>> + u64 *devtbl = its->tables[its->dev_table_idx];
>> + u32 alloc_size = (1 << its->order) * PAGE_SIZE;
>> + u32 idx = dev_id >> its->dev_table_shift;
> All this should be explained. I don't want to have to refer to the spec
> to understand how you're computing things. It also means that you need
> to define some helpers.
I will add helper functions/macros for handy conversion.
>> + struct page *page;
>> +
>> + /* Do nothing if the level-2 DEV-ITT entry was mapped earlier */
> There is no such thing as a DEV-ITT. There is a Device table (what you
> are allocating here), and a per-device ITT, which is not dealt with here
> at all.
I will rename all references of DEV-ITT to device table.
>> + if (devtbl[idx])
>> + return 0;
>> +
>> + /* Allocate memory for level-2 device table & map to level-1 table */
>> + page = alloc_pages(GFP_KERNEL | __GFP_ZERO, its->order);
>> + if (!page)
>> + return -ENOMEM;
>> +
>> + devtbl[idx] = page_to_phys(page) | GITS_BASER_VALID;
>> +
>> + if (its->flags & ITS_FLAGS_DEVICE_NEEDS_FLUSHING) {
>> + __flush_dcache_area(page_address(page), alloc_size);
>> + __flush_dcache_area(devtbl + idx, sizeof(*devtbl));
>> + }
>> +
>> + return 0;
> It really time we convert this driver to use dma_alloc_coherent. This is
> getting out of control...
dma_alloc_coherent() API operates on “struct device”. We don’t have
such device object available in current ITS driver to call DMA API.
>> +}
>> +
>> static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
>> int nvecs)
>> {
>> @@ -1147,6 +1202,20 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
>> int nr_ites;
>> int sz;
>>
>> + if (dev_id > its->max_devid) {
>> + pr_err("ITS: dev_id too large %d\n", dev_id);
>> + return NULL;
>> + }
> Under which circumstances can this actually happen?
Current driver assumes the device memory has been allocated to cover
all possible DEVIDs but is not always true.
This is perfect as long as sparse DEVID is small and if we don’t see the
message “Device Table too large, reduce its page order to”
in its_alloc_tables() .
As per GICv3-ITS spec, the MAPD command with DEV ID exceeding maximum
value supported is an error. The current driver logic
doesn't protect against this error.
>> +
>> + /* Ensure memory for level-2 table is allocated for dev_id */
>> + if (its->flags & ITS_FLAGS_INDIRECT_DEVICE_TABLE) {
>> + int ret;
>> +
>> + ret = its_alloc_device_table(its, dev_id);
>> + if (ret)
>> + return NULL;
>> + }
>> +
>> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>> /*
>> * At least one bit of EventID is being used, hence a minimum
>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
>> index d5d798b..04dfe09 100644
>> --- a/include/linux/irqchip/arm-gic-v3.h
>> +++ b/include/linux/irqchip/arm-gic-v3.h
>> @@ -206,6 +206,7 @@
>> #define GITS_BASER_NR_REGS 8
>>
>> #define GITS_BASER_VALID (1UL << 63)
>> +#define GITS_BASER_INDIRECT (1UL << 62)
>> #define GITS_BASER_nCnB (0UL << 59)
>> #define GITS_BASER_nC (1UL << 59)
>> #define GITS_BASER_RaWt (2UL << 59)
>>
> Thanks,
>
> M.
More information about the linux-arm-kernel
mailing list