* [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing
@ 2021-09-24 6:19 pdel
2021-09-24 6:19 ` [PATCH 1/1] " pdel
0 siblings, 1 reply; 7+ messages in thread
From: pdel @ 2021-09-24 6:19 UTC (permalink / raw)
Cc: clg, joel, rashmica.g, patrick, qemu-devel, Peter Delevoryas
From: Peter Delevoryas <pdel@fb.com>
Hey everyone,
I think there might be a bug aspeed_gpio_update, when it's selecting a
GPIO IRQ to update. I was testing booting Facebook's OpenBMC platform
"YosemiteV2" (fby2), and I was hitting a segfault in QEMU:
qemu-system-arm -machine ast2500-evb \
-drive file=fby2.mtd,format=raw,if=mtd \
-serial stdio -display none
...
Setup Caching for Bridge IC info..done.
Setup Front Panel Daemon..done.
Setup fan speed...
FAN CONFIG : Single Rotor FAN
Unexpected 4 Servers config! Run FSC 4 TLs Config as default config
Setting Zone 0 speed to 70%
Setting Zone 1 speed to 70%
ok: run: fscd: (pid 1726) 0s
done.
Powering fru 1 to ON state...
Segmentation fault (core dumped)
In gdb:
Thread 3 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff20ee700 (LWP 1840353)]
qemu_set_irq (irq=0xffffffff00000000, level=1) at ../hw/core/irq.c:45
45 irq->handler(irq->opaque, irq->n, level);
(gdb) p irq
$1 = (qemu_irq) 0xffffffff00000000
(gdb) up
#1 0x00005555558e36f5 in aspeed_gpio_update (s=0x7ffff7ecffb0, regs=0x7ffff7ed0c94, value=128) at ../hw/gpio/aspeed_gpio.c:287
287 qemu_set_irq(s->gpios[offset], !!(new & mask));
(gdb) p s->gpios
$2 = {0x0 <repeats 228 times>}
(gdb) p offset
$3 = 231
(gdb) p set
$5 = 7
(gdb) p gpio
$4 = 7
The commit message for the fix has a little more info on the bug here,
see that for more info.
I tested this by verifying that after this diff, I can boot this fby2
platform. I don't see any unit or qtest's for aspeed gpio's, maybe I
could add one? I figured that, first, I could just put out an email to
let everyone know about it, and get the diff reviewed.
The image I was using is here:
https://github.com/peterdelevoryas/openbmc/releases/tag/fby2.debug.mtd
Peter Delevoryas (1):
hw: aspeed_gpio: Fix GPIO array indexing
hw/gpio/aspeed_gpio.c | 80 +++++++++++++++--------------------
include/hw/gpio/aspeed_gpio.h | 5 +--
2 files changed, 35 insertions(+), 50 deletions(-)
--
2.30.2
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/1] hw: aspeed_gpio: Fix GPIO array indexing
2021-09-24 6:19 [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing pdel
@ 2021-09-24 6:19 ` pdel
2021-09-25 11:02 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 7+ messages in thread
From: pdel @ 2021-09-24 6:19 UTC (permalink / raw)
Cc: clg, joel, rashmica.g, patrick, qemu-devel, Peter Delevoryas
From: Peter Delevoryas <pdel@fb.com>
The gpio array is declared as a dense array:
...
qemu_irq gpios[ASPEED_GPIO_NR_PINS];
(AST2500 has 228, AST2400 has 216, AST2600 has 208)
However, this array is used like a matrix of GPIO sets
(e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
size_t offset = set * GPIOS_PER_SET + gpio;
qemu_set_irq(s->gpios[offset], !!(new & mask));
This can result in an out-of-bounds access to "s->gpios" because the
gpio sets do _not_ have the same length. Some of the groups (e.g.
GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
To fix this, I converted the gpio array from dense to sparse, to that
match both the hardware layout and this existing indexing code.
Also, I noticed that some of the property specifications looked wrong:
the lower 8 bits in the input and output u32's correspond to the first
group label, and the upper 8 bits correspond to the last group label.
I looked at the datasheet and several of these declarations seemed
incorrect to me (I was basing it off of the I/O column). If somebody
can double-check this, I'd really appreciate it!
Some were definitely wrong though, like "Y" and "Z" in the 2600.
@@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
[3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
[4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
[5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
- [6] = {0xffffff0f, 0x0fffff0f, {"Y", "Z", "AA", "AB"} },
+ [6] = {0x0fffffff, 0x0fffffff, {"Y", "Z", "AA", "AB"} },
[7] = {0x000000ff, 0x000000ff, {"AC"} },
};
@@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
[1] = {0xffffffff, 0xffffffff, {"E", "F", "G", "H"} },
[2] = {0xffffffff, 0xffffffff, {"I", "J", "K", "L"} },
[3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
- [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
- [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
- [6] = {0xffff0000, 0x0fff0000, {"Y", "Z", "", ""} },
+ [4] = {0xffffffff, 0x00ffffff, {"Q", "R", "S", "T"} },
+ [5] = {0xffffffff, 0xffffff00, {"U", "V", "W", "X"} },
+ [6] = {0x0000ffff, 0x0000ffff, {"Y", "Z", "", ""} },
};
Signed-off-by: Peter Delevoryas <pdel@fb.com>
---
hw/gpio/aspeed_gpio.c | 80 +++++++++++++++--------------------
include/hw/gpio/aspeed_gpio.h | 5 +--
2 files changed, 35 insertions(+), 50 deletions(-)
diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index dfa6d6cb40..8e3f7e4398 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -16,11 +16,7 @@
#include "hw/irq.h"
#include "migration/vmstate.h"
-#define GPIOS_PER_REG 32
-#define GPIOS_PER_SET GPIOS_PER_REG
-#define GPIO_PIN_GAP_SIZE 4
#define GPIOS_PER_GROUP 8
-#define GPIO_GROUP_SHIFT 3
/* GPIO Source Types */
#define ASPEED_CMD_SRC_MASK 0x01010101
@@ -259,7 +255,7 @@ static void aspeed_gpio_update(AspeedGPIOState *s, GPIOSets *regs,
diff = old ^ new;
if (diff) {
- for (gpio = 0; gpio < GPIOS_PER_REG; gpio++) {
+ for (gpio = 0; gpio < ASPEED_GPIOS_PER_SET; gpio++) {
uint32_t mask = 1 << gpio;
/* If the gpio needs to be updated... */
@@ -283,8 +279,7 @@ static void aspeed_gpio_update(AspeedGPIOState *s, GPIOSets *regs,
if (direction & mask) {
/* ...trigger the line-state IRQ */
ptrdiff_t set = aspeed_gpio_set_idx(s, regs);
- size_t offset = set * GPIOS_PER_SET + gpio;
- qemu_set_irq(s->gpios[offset], !!(new & mask));
+ qemu_set_irq(s->gpios[set][gpio], !!(new & mask));
} else {
/* ...otherwise if we meet the line's current IRQ policy... */
if (aspeed_evaluate_irq(regs, old & mask, gpio)) {
@@ -297,21 +292,6 @@ static void aspeed_gpio_update(AspeedGPIOState *s, GPIOSets *regs,
qemu_set_irq(s->irq, !!(s->pending));
}
-static uint32_t aspeed_adjust_pin(AspeedGPIOState *s, uint32_t pin)
-{
- AspeedGPIOClass *agc = ASPEED_GPIO_GET_CLASS(s);
- /*
- * The 2500 has a 4 pin gap in group AB and the 2400 has a 4 pin
- * gap in group Y (and only four pins in AB but this is the last group so
- * it doesn't matter).
- */
- if (agc->gap && pin >= agc->gap) {
- pin += GPIO_PIN_GAP_SIZE;
- }
-
- return pin;
-}
-
static bool aspeed_gpio_get_pin_level(AspeedGPIOState *s, uint32_t set_idx,
uint32_t pin)
{
@@ -367,7 +347,7 @@ static uint32_t update_value_control_source(GPIOSets *regs, uint32_t old_value,
uint32_t new_value = 0;
/* for each group in set */
- for (i = 0; i < GPIOS_PER_REG; i += GPIOS_PER_GROUP) {
+ for (i = 0; i < ASPEED_GPIOS_PER_SET; i += GPIOS_PER_GROUP) {
cmd_source = extract32(regs->cmd_source_0, i, 1)
| (extract32(regs->cmd_source_1, i, 1) << 1);
@@ -637,7 +617,7 @@ static void aspeed_gpio_write(void *opaque, hwaddr offset, uint64_t data,
* bidirectional | 1 | 1 | data
* input only | 1 | 0 | 0
* output only | 0 | 1 | 1
- * no pin / gap | 0 | 0 | 0
+ * no pin | 0 | 0 | 0
*
* which is captured by:
* data = ( data | ~input) & output;
@@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
[3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
[4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
[5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
- [6] = {0xffffff0f, 0x0fffff0f, {"Y", "Z", "AA", "AB"} },
+ [6] = {0x0fffffff, 0x0fffffff, {"Y", "Z", "AA", "AB"} },
[7] = {0x000000ff, 0x000000ff, {"AC"} },
};
@@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
[1] = {0xffffffff, 0xffffffff, {"E", "F", "G", "H"} },
[2] = {0xffffffff, 0xffffffff, {"I", "J", "K", "L"} },
[3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
- [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
- [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
- [6] = {0xffff0000, 0x0fff0000, {"Y", "Z", "", ""} },
+ [4] = {0xffffffff, 0x00ffffff, {"Q", "R", "S", "T"} },
+ [5] = {0xffffffff, 0xffffff00, {"U", "V", "W", "X"} },
+ [6] = {0x0000ffff, 0x0000ffff, {"Y", "Z", "", ""} },
};
static GPIOSetProperties ast2600_1_8v_set_props[] = {
@@ -836,14 +816,20 @@ static void aspeed_gpio_realize(DeviceState *dev, Error **errp)
AspeedGPIOState *s = ASPEED_GPIO(dev);
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
AspeedGPIOClass *agc = ASPEED_GPIO_GET_CLASS(s);
- int pin;
/* Interrupt parent line */
sysbus_init_irq(sbd, &s->irq);
/* Individual GPIOs */
- for (pin = 0; pin < agc->nr_gpio_pins; pin++) {
- sysbus_init_irq(sbd, &s->gpios[pin]);
+ for (int i = 0; i < ASPEED_GPIO_MAX_NR_SETS; i++) {
+ const GPIOSetProperties *props = &agc->props[i];
+ uint32_t skip = ~(props->input | props->output);
+ for (int j = 0; j < ASPEED_GPIOS_PER_SET; j++) {
+ if (skip >> j & 1) {
+ continue;
+ }
+ sysbus_init_irq(sbd, &s->gpios[i][j]);
+ }
}
memory_region_init_io(&s->iomem, OBJECT(s), &aspeed_gpio_ops, s,
@@ -856,20 +842,22 @@ static void aspeed_gpio_init(Object *obj)
{
AspeedGPIOState *s = ASPEED_GPIO(obj);
AspeedGPIOClass *agc = ASPEED_GPIO_GET_CLASS(s);
- int pin;
-
- for (pin = 0; pin < agc->nr_gpio_pins; pin++) {
- char *name;
- int set_idx = pin / GPIOS_PER_SET;
- int pin_idx = aspeed_adjust_pin(s, pin) - (set_idx * GPIOS_PER_SET);
- int group_idx = pin_idx >> GPIO_GROUP_SHIFT;
- const GPIOSetProperties *props = &agc->props[set_idx];
-
- name = g_strdup_printf("gpio%s%d", props->group_label[group_idx],
- pin_idx % GPIOS_PER_GROUP);
- object_property_add(obj, name, "bool", aspeed_gpio_get_pin,
- aspeed_gpio_set_pin, NULL, NULL);
- g_free(name);
+
+ for (int i = 0; i < ASPEED_GPIO_MAX_NR_SETS; i++) {
+ const GPIOSetProperties *props = &agc->props[i];
+ uint32_t skip = ~(props->input | props->output);
+ for (int j = 0; j < ASPEED_GPIOS_PER_SET; j++) {
+ if (skip >> j & 1) {
+ continue;
+ }
+ int group_idx = j / GPIOS_PER_GROUP;
+ int pin_idx = j % GPIOS_PER_GROUP;
+ const char *group = &props->group_label[group_idx][0];
+ char *name = g_strdup_printf("gpio%s%d", group, pin_idx);
+ object_property_add(obj, name, "bool", aspeed_gpio_get_pin,
+ aspeed_gpio_set_pin, NULL, NULL);
+ g_free(name);
+ }
}
}
@@ -926,7 +914,6 @@ static void aspeed_gpio_ast2400_class_init(ObjectClass *klass, void *data)
agc->props = ast2400_set_props;
agc->nr_gpio_pins = 216;
agc->nr_gpio_sets = 7;
- agc->gap = 196;
agc->reg_table = aspeed_3_3v_gpios;
}
@@ -937,7 +924,6 @@ static void aspeed_gpio_2500_class_init(ObjectClass *klass, void *data)
agc->props = ast2500_set_props;
agc->nr_gpio_pins = 228;
agc->nr_gpio_sets = 8;
- agc->gap = 220;
agc->reg_table = aspeed_3_3v_gpios;
}
diff --git a/include/hw/gpio/aspeed_gpio.h b/include/hw/gpio/aspeed_gpio.h
index e1636ce7fe..801846befb 100644
--- a/include/hw/gpio/aspeed_gpio.h
+++ b/include/hw/gpio/aspeed_gpio.h
@@ -17,9 +17,9 @@
OBJECT_DECLARE_TYPE(AspeedGPIOState, AspeedGPIOClass, ASPEED_GPIO)
#define ASPEED_GPIO_MAX_NR_SETS 8
+#define ASPEED_GPIOS_PER_SET 32
#define ASPEED_REGS_PER_BANK 14
#define ASPEED_GPIO_MAX_NR_REGS (ASPEED_REGS_PER_BANK * ASPEED_GPIO_MAX_NR_SETS)
-#define ASPEED_GPIO_NR_PINS 228
#define ASPEED_GROUPS_PER_SET 4
#define ASPEED_GPIO_NR_DEBOUNCE_REGS 3
#define ASPEED_CHARS_PER_GROUP_LABEL 4
@@ -60,7 +60,6 @@ struct AspeedGPIOClass {
const GPIOSetProperties *props;
uint32_t nr_gpio_pins;
uint32_t nr_gpio_sets;
- uint32_t gap;
const AspeedGPIOReg *reg_table;
};
@@ -72,7 +71,7 @@ struct AspeedGPIOState {
MemoryRegion iomem;
int pending;
qemu_irq irq;
- qemu_irq gpios[ASPEED_GPIO_NR_PINS];
+ qemu_irq gpios[ASPEED_GPIO_MAX_NR_SETS][ASPEED_GPIOS_PER_SET];
/* Parallel GPIO Registers */
uint32_t debounce_regs[ASPEED_GPIO_NR_DEBOUNCE_REGS];
--
2.30.2
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] hw: aspeed_gpio: Fix GPIO array indexing
2021-09-24 6:19 ` [PATCH 1/1] " pdel
@ 2021-09-25 11:02 ` Philippe Mathieu-Daudé
2021-09-25 14:28 ` Peter Delevoryas
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-25 11:02 UTC (permalink / raw)
To: pdel; +Cc: qemu-devel, patrick, rashmica.g, clg, joel
Hi Peter,
On 9/24/21 08:19, pdel@fb.com wrote:
> From: Peter Delevoryas <pdel@fb.com>
>
> The gpio array is declared as a dense array:
>
> ...
> qemu_irq gpios[ASPEED_GPIO_NR_PINS];
>
> (AST2500 has 228, AST2400 has 216, AST2600 has 208)
>
> However, this array is used like a matrix of GPIO sets
> (e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
>
> size_t offset = set * GPIOS_PER_SET + gpio;
> qemu_set_irq(s->gpios[offset], !!(new & mask));
>
> This can result in an out-of-bounds access to "s->gpios" because the
> gpio sets do _not_ have the same length. Some of the groups (e.g.
> GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
>
> To fix this, I converted the gpio array from dense to sparse, to that
> match both the hardware layout and this existing indexing code.
This is one logical change: 1 patch
> Also, I noticed that some of the property specifications looked wrong:
> the lower 8 bits in the input and output u32's correspond to the first
> group label, and the upper 8 bits correspond to the last group label.
Another logical change: another patch :)
So please split this patch in 2. Maybe easier to fix GPIOSetProperties
first, then convert from dense to sparse array.
Regards,
Phil.
> I looked at the datasheet and several of these declarations seemed
> incorrect to me (I was basing it off of the I/O column). If somebody
> can double-check this, I'd really appreciate it!
>
> Some were definitely wrong though, like "Y" and "Z" in the 2600.
>
> @@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
> [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
> [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
> - [6] = {0xffffff0f, 0x0fffff0f, {"Y", "Z", "AA", "AB"} },
> + [6] = {0x0fffffff, 0x0fffffff, {"Y", "Z", "AA", "AB"} },
> [7] = {0x000000ff, 0x000000ff, {"AC"} },
> };
>
> @@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
> [1] = {0xffffffff, 0xffffffff, {"E", "F", "G", "H"} },
> [2] = {0xffffffff, 0xffffffff, {"I", "J", "K", "L"} },
> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
> - [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
> - [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
> - [6] = {0xffff0000, 0x0fff0000, {"Y", "Z", "", ""} },
> + [4] = {0xffffffff, 0x00ffffff, {"Q", "R", "S", "T"} },
> + [5] = {0xffffffff, 0xffffff00, {"U", "V", "W", "X"} },
> + [6] = {0x0000ffff, 0x0000ffff, {"Y", "Z", "", ""} },
> };
>
> Signed-off-by: Peter Delevoryas <pdel@fb.com>
> ---
> hw/gpio/aspeed_gpio.c | 80 +++++++++++++++--------------------
> include/hw/gpio/aspeed_gpio.h | 5 +--
> 2 files changed, 35 insertions(+), 50 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] hw: aspeed_gpio: Fix GPIO array indexing
2021-09-25 11:02 ` Philippe Mathieu-Daudé
@ 2021-09-25 14:28 ` Peter Delevoryas
2021-09-27 10:05 ` Cédric Le Goater
0 siblings, 1 reply; 7+ messages in thread
From: Peter Delevoryas @ 2021-09-25 14:28 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: clg, joel, rashmica.g, patrick, qemu-devel
> On Sep 25, 2021, at 4:03 AM, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> Hi Peter,
>
>> On 9/24/21 08:19, pdel@fb.com wrote:
>> From: Peter Delevoryas <pdel@fb.com>
>> The gpio array is declared as a dense array:
>> ...
>> qemu_irq gpios[ASPEED_GPIO_NR_PINS];
>> (AST2500 has 228, AST2400 has 216, AST2600 has 208)
>> However, this array is used like a matrix of GPIO sets
>> (e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
>> size_t offset = set * GPIOS_PER_SET + gpio;
>> qemu_set_irq(s->gpios[offset], !!(new & mask));
>> This can result in an out-of-bounds access to "s->gpios" because the
>> gpio sets do _not_ have the same length. Some of the groups (e.g.
>> GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
>> To fix this, I converted the gpio array from dense to sparse, to that
>> match both the hardware layout and this existing indexing code.
>
> This is one logical change: 1 patch
>
>> Also, I noticed that some of the property specifications looked wrong:
>> the lower 8 bits in the input and output u32's correspond to the first
>> group label, and the upper 8 bits correspond to the last group label.
>
> Another logical change: another patch :)
>
> So please split this patch in 2. Maybe easier to fix GPIOSetProperties
> first, then convert from dense to sparse array.
>
Good point, I’ll split it up then!
> Regards,
>
> Phil.
>
>> I looked at the datasheet and several of these declarations seemed
>> incorrect to me (I was basing it off of the I/O column). If somebody
>> can double-check this, I'd really appreciate it!
>> Some were definitely wrong though, like "Y" and "Z" in the 2600.
>> @@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
>> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
>> [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
>> [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
>> - [6] = {0xffffff0f, 0x0fffff0f, {"Y", "Z", "AA", "AB"} },
>> + [6] = {0x0fffffff, 0x0fffffff, {"Y", "Z", "AA", "AB"} },
>> [7] = {0x000000ff, 0x000000ff, {"AC"} },
>> };
>> @@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
>> [1] = {0xffffffff, 0xffffffff, {"E", "F", "G", "H"} },
>> [2] = {0xffffffff, 0xffffffff, {"I", "J", "K", "L"} },
>> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
>> - [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
>> - [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
>> - [6] = {0xffff0000, 0x0fff0000, {"Y", "Z", "", ""} },
>> + [4] = {0xffffffff, 0x00ffffff, {"Q", "R", "S", "T"} },
>> + [5] = {0xffffffff, 0xffffff00, {"U", "V", "W", "X"} },
>> + [6] = {0x0000ffff, 0x0000ffff, {"Y", "Z", "", ""} },
>> };
>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>> ---
>> hw/gpio/aspeed_gpio.c | 80 +++++++++++++++--------------------
>> include/hw/gpio/aspeed_gpio.h | 5 +--
>> 2 files changed, 35 insertions(+), 50 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] hw: aspeed_gpio: Fix GPIO array indexing
2021-09-25 14:28 ` Peter Delevoryas
@ 2021-09-27 10:05 ` Cédric Le Goater
0 siblings, 0 replies; 7+ messages in thread
From: Cédric Le Goater @ 2021-09-27 10:05 UTC (permalink / raw)
To: Peter Delevoryas, Philippe Mathieu-Daudé
Cc: patrick, rashmica.g, joel, qemu-devel
On 9/25/21 16:28, Peter Delevoryas wrote:
>
>> On Sep 25, 2021, at 4:03 AM, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Hi Peter,
>>
>>> On 9/24/21 08:19, pdel@fb.com wrote:
>>> From: Peter Delevoryas <pdel@fb.com>
>>> The gpio array is declared as a dense array:
>>> ...
>>> qemu_irq gpios[ASPEED_GPIO_NR_PINS];
>>> (AST2500 has 228, AST2400 has 216, AST2600 has 208)
>>> However, this array is used like a matrix of GPIO sets
>>> (e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
>>> size_t offset = set * GPIOS_PER_SET + gpio;
>>> qemu_set_irq(s->gpios[offset], !!(new & mask));
>>> This can result in an out-of-bounds access to "s->gpios" because the
>>> gpio sets do _not_ have the same length. Some of the groups (e.g.
>>> GPIOAB) only have 4 pins. 228 != 8 * 32 == 256.
>>> To fix this, I converted the gpio array from dense to sparse, to that
>>> match both the hardware layout and this existing indexing code.
>>
>> This is one logical change: 1 patch
>>
>>> Also, I noticed that some of the property specifications looked wrong:
>>> the lower 8 bits in the input and output u32's correspond to the first
>>> group label, and the upper 8 bits correspond to the last group label.
>>
>> Another logical change: another patch :)
>>
>> So please split this patch in 2. Maybe easier to fix GPIOSetProperties
>> first, then convert from dense to sparse array.
>>
>
> Good point, I’ll split it up then!
Yes. We can surely merge the GPIOSetProperties patch quickly.
I hope Rashmica has some time to check the second part.
Thanks,
C.
>
>> Regards,
>>
>> Phil.
>>
>>> I looked at the datasheet and several of these declarations seemed
>>> incorrect to me (I was basing it off of the I/O column). If somebody
>>> can double-check this, I'd really appreciate it!
>>> Some were definitely wrong though, like "Y" and "Z" in the 2600.
>>> @@ -796,7 +776,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
>>> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
>>> [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
>>> [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
>>> - [6] = {0xffffff0f, 0x0fffff0f, {"Y", "Z", "AA", "AB"} },
>>> + [6] = {0x0fffffff, 0x0fffffff, {"Y", "Z", "AA", "AB"} },
>>> [7] = {0x000000ff, 0x000000ff, {"AC"} },
>>> };
>>> @@ -805,9 +785,9 @@ static GPIOSetProperties ast2600_3_3v_set_props[] = {
>>> [1] = {0xffffffff, 0xffffffff, {"E", "F", "G", "H"} },
>>> [2] = {0xffffffff, 0xffffffff, {"I", "J", "K", "L"} },
>>> [3] = {0xffffffff, 0xffffffff, {"M", "N", "O", "P"} },
>>> - [4] = {0xffffffff, 0xffffffff, {"Q", "R", "S", "T"} },
>>> - [5] = {0xffffffff, 0x0000ffff, {"U", "V", "W", "X"} },
>>> - [6] = {0xffff0000, 0x0fff0000, {"Y", "Z", "", ""} },
>>> + [4] = {0xffffffff, 0x00ffffff, {"Q", "R", "S", "T"} },
>>> + [5] = {0xffffffff, 0xffffff00, {"U", "V", "W", "X"} },
>>> + [6] = {0x0000ffff, 0x0000ffff, {"Y", "Z", "", ""} },
>>> };
>>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>>> ---
>>> hw/gpio/aspeed_gpio.c | 80 +++++++++++++++--------------------
>>> include/hw/gpio/aspeed_gpio.h | 5 +--
>>> 2 files changed, 35 insertions(+), 50 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing
2021-09-28 3:43 [PATCH 0/1] " pdel
@ 2021-09-30 0:46 ` Peter Delevoryas
0 siblings, 0 replies; 7+ messages in thread
From: Peter Delevoryas @ 2021-09-30 0:46 UTC (permalink / raw)
Cc: Cédric Le Goater, Joel Stanley, rashmica.g, patrick,
Cameron Esfahani via, Philippe Mathieu-Daudé,
Dan Zhang
> On Sep 27, 2021, at 8:43 PM, pdel@fb.com wrote:
>
> From: Peter Delevoryas <pdel@fb.com>
>
> Hey everyone,
>
> I think there might be a bug in aspeed_gpio_update, where it's selecting
> a GPIO IRQ to update. The indexing that maps from GPIO pin to IRQ leads
> to an out-of-bounds array access and a segfault after that.
>
> tl;dr
>
> There's 8 rows of 32 pins (8 * 32 == 256 total) on the AST2500, but some
> of the pins are not actually active: there's only 228 pins actually
> active in the AST2500.
>
> The GPIO IRQ array has length 228, but we index it using a matrix
> indexing scheme like [row][column], and end up out-of-bounds for
> high-numbered pins.
>
> I fixed this by converting the IRQ array to a matrix, where some
> of the entries are uninitialized (zero). This retains the matrix
> indexing scheme, which I think is easy to understand.
>
> Notes on reproducing:
>
> I was testing booting Facebook's OpenBMC platform "YosemiteV2" (fby2)
> and hit a segfault:
>
> qemu-system-arm -machine ast2500-evb \
> -drive file=fby2.mtd,format=raw,if=mtd \
> -serial stdio -display none
> ...
> Setup Caching for Bridge IC info..done.
> Setup Front Panel Daemon..done.
> Setup fan speed...
> FAN CONFIG : Single Rotor FAN
> Unexpected 4 Servers config! Run FSC 4 TLs Config as default config
> Setting Zone 0 speed to 70%
> Setting Zone 1 speed to 70%
> ok: run: fscd: (pid 1726) 0s
> done.
> Powering fru 1 to ON state...
> Segmentation fault (core dumped)
>
> In gdb:
>
> Thread 3 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff20ee700 (LWP 1840353)]
> qemu_set_irq (irq=0xffffffff00000000, level=1) at ../hw/core/irq.c:45
> 45 irq->handler(irq->opaque, irq->n, level);
> (gdb) p irq
> $1 = (qemu_irq) 0xffffffff00000000
> (gdb) up
> #1 0x00005555558e36f5 in aspeed_gpio_update (s=0x7ffff7ecffb0, regs=0x7ffff7ed0c94, value=128) at ../hw/gpio/aspeed_gpio.c:287
> 287 qemu_set_irq(s->gpios[offset], !!(new & mask));
> (gdb) p s->gpios
> $2 = {0x0 <repeats 228 times>}
> (gdb) p offset
> $3 = 231
> (gdb) p set
> $5 = 7
> (gdb) p gpio
> $4 = 7
>
> With my fix, I can boot the fby2 platform. The image I was using is here:
>
> https://github.com/peterdelevoryas/openbmc/releases/tag/fby2.debug.mtd
>
> Peter Delevoryas (1):
> hw: aspeed_gpio: Fix GPIO array indexing
>
> hw/gpio/aspeed_gpio.c | 72 ++++++++++++++---------------------
> include/hw/gpio/aspeed_gpio.h | 5 +--
> 2 files changed, 31 insertions(+), 46 deletions(-)
>
> --
> 2.30.2
>
cc’ing Dan
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing
@ 2021-09-28 3:43 pdel
2021-09-30 0:46 ` Peter Delevoryas
0 siblings, 1 reply; 7+ messages in thread
From: pdel @ 2021-09-28 3:43 UTC (permalink / raw)
Cc: clg, joel, rashmica.g, patrick, qemu-devel, f4bug, Peter Delevoryas
From: Peter Delevoryas <pdel@fb.com>
Hey everyone,
I think there might be a bug in aspeed_gpio_update, where it's selecting
a GPIO IRQ to update. The indexing that maps from GPIO pin to IRQ leads
to an out-of-bounds array access and a segfault after that.
tl;dr
There's 8 rows of 32 pins (8 * 32 == 256 total) on the AST2500, but some
of the pins are not actually active: there's only 228 pins actually
active in the AST2500.
The GPIO IRQ array has length 228, but we index it using a matrix
indexing scheme like [row][column], and end up out-of-bounds for
high-numbered pins.
I fixed this by converting the IRQ array to a matrix, where some
of the entries are uninitialized (zero). This retains the matrix
indexing scheme, which I think is easy to understand.
Notes on reproducing:
I was testing booting Facebook's OpenBMC platform "YosemiteV2" (fby2)
and hit a segfault:
qemu-system-arm -machine ast2500-evb \
-drive file=fby2.mtd,format=raw,if=mtd \
-serial stdio -display none
...
Setup Caching for Bridge IC info..done.
Setup Front Panel Daemon..done.
Setup fan speed...
FAN CONFIG : Single Rotor FAN
Unexpected 4 Servers config! Run FSC 4 TLs Config as default config
Setting Zone 0 speed to 70%
Setting Zone 1 speed to 70%
ok: run: fscd: (pid 1726) 0s
done.
Powering fru 1 to ON state...
Segmentation fault (core dumped)
In gdb:
Thread 3 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff20ee700 (LWP 1840353)]
qemu_set_irq (irq=0xffffffff00000000, level=1) at ../hw/core/irq.c:45
45 irq->handler(irq->opaque, irq->n, level);
(gdb) p irq
$1 = (qemu_irq) 0xffffffff00000000
(gdb) up
#1 0x00005555558e36f5 in aspeed_gpio_update (s=0x7ffff7ecffb0, regs=0x7ffff7ed0c94, value=128) at ../hw/gpio/aspeed_gpio.c:287
287 qemu_set_irq(s->gpios[offset], !!(new & mask));
(gdb) p s->gpios
$2 = {0x0 <repeats 228 times>}
(gdb) p offset
$3 = 231
(gdb) p set
$5 = 7
(gdb) p gpio
$4 = 7
With my fix, I can boot the fby2 platform. The image I was using is here:
https://github.com/peterdelevoryas/openbmc/releases/tag/fby2.debug.mtd
Peter Delevoryas (1):
hw: aspeed_gpio: Fix GPIO array indexing
hw/gpio/aspeed_gpio.c | 72 ++++++++++++++---------------------
include/hw/gpio/aspeed_gpio.h | 5 +--
2 files changed, 31 insertions(+), 46 deletions(-)
--
2.30.2
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-30 0:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-24 6:19 [PATCH 0/1] hw: aspeed_gpio: Fix GPIO array indexing pdel
2021-09-24 6:19 ` [PATCH 1/1] " pdel
2021-09-25 11:02 ` Philippe Mathieu-Daudé
2021-09-25 14:28 ` Peter Delevoryas
2021-09-27 10:05 ` Cédric Le Goater
2021-09-28 3:43 [PATCH 0/1] " pdel
2021-09-30 0:46 ` Peter Delevoryas
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).