[PATCH 0/2] hw/gpio/aspeed: Don't let guests modify input pins

[PATCH 0/2] hw/gpio/aspeed: Don't let guests modify input pins

[Peter Delevoryas]

The fby35 OpenBMC sysvinit scripts check various GPIO pins at start and
decide where to start IPMB daemons for each slot in the sled (4 slots max).
It only starts an IPMB daemon if the slot GPIO pins indicate that it's
present and powered on.

I've been simulating some input pins by setting their value in the machine
reset function. I think a proper solution would be to add input pins to the
Aspeed GPIO code and create devices that force the pins high or low
appropriately, but for now setting the QOM property seemed fine.

But, I noticed that while the values were set initially, something in the
boot process resets all the values I set to "low". I imagine something in
userspace or the driver is blanket writing zero to the data registers. I
think the Aspeed GPIO controller probably shouldn't be changing the value of
input pins in this case.

To fix this, we could just make sure that aspeed_gpio_update() never sets
the value of an input pin. However, that would also prevent my code in
fby35_reset from initializing the input pins to some special value. So, to
support the QOM property setup use-case, I added a "force" parameter. Kinda
hacky, but it was the simplest thing I could think of.

Thanks,
Peter

Peter Delevoryas (2):
  hw/gpio/aspeed: Don't let guests modify input pins
  aspeed: Add fby35-bmc slot GPIO's

 hw/arm/aspeed.c       | 14 +++++++++++++-
 hw/gpio/aspeed_gpio.c | 22 ++++++++++++----------
 2 files changed, 25 insertions(+), 11 deletions(-)

-- 
2.36.1

Re: [PATCH 0/2] hw/gpio/aspeed: Don't let guests modify input pins

[Peter Delevoryas]

On Thu, Jul 07, 2022 at 12:17:29AM -0700, Peter Delevoryas wrote:
> The fby35 OpenBMC sysvinit scripts check various GPIO pins at start and
> decide where to start IPMB daemons for each slot in the sled (4 slots max).
> It only starts an IPMB daemon if the slot GPIO pins indicate that it's
> present and powered on.
> 
> I've been simulating some input pins by setting their value in the machine
> reset function. I think a proper solution would be to add input pins to the
> Aspeed GPIO code and create devices that force the pins high or low
> appropriately, but for now setting the QOM property seemed fine.
> 
> But, I noticed that while the values were set initially, something in the
> boot process resets all the values I set to "low". I imagine something in
> userspace or the driver is blanket writing zero to the data registers. I
> think the Aspeed GPIO controller probably shouldn't be changing the value of
> input pins in this case.
> 
> To fix this, we could just make sure that aspeed_gpio_update() never sets
> the value of an input pin. However, that would also prevent my code in
> fby35_reset from initializing the input pins to some special value. So, to
> support the QOM property setup use-case, I added a "force" parameter. Kinda
> hacky, but it was the simplest thing I could think of.
> 
> Thanks,
> Peter

My gitconfig was messed up, I was using the maintainers.pl script in my
send-email.ccCmd, but that doesn't work for the cover letter.  So, it just sent
the cover letter to me. I didn't notice it in test emailing cause I usually just
test sending to myself. Sorry about this. Hopefully I should finally have
my email configuration fixed at this point...I hope.

Peter

> 
> Peter Delevoryas (2):
>   hw/gpio/aspeed: Don't let guests modify input pins
>   aspeed: Add fby35-bmc slot GPIO's
> 
>  hw/arm/aspeed.c       | 14 +++++++++++++-
>  hw/gpio/aspeed_gpio.c | 22 ++++++++++++----------
>  2 files changed, 25 insertions(+), 11 deletions(-)
> 
> -- 
> 2.36.1
>