Re: trying to get qom-{get,set} working with gpio on qemu-x86_64

[John Snow]

On Thu, Feb 24, 2022 at 6:39 AM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>
> On 24/02/2022 11:05, Peter Maydell wrote:
> > On Thu, 24 Feb 2022 at 10:53, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> >> I have been trying to get qom-get/qom-set scripts working to make an
> >> virtual GPIO device on qemu-system-x86_64. I have a working TMP105
> >> and I can see the MAX7310 being instantiated with the relevant Linux
> >> devices showing up (i2c, gpio).
> >>
> >> I can read the sensor from QEmu console:
> >>
> >> (qemu)  qom-get /machine/peripheral/sensor temperature
> >> 20000
> >> (qemu) qom-set  /machine/peripheral/sensor temperature 19000
> >> (qemu)  qom-get /machine/peripheral/sensor temperature
> >> 19000
> >>
> >> When trying to get or set anything from the GPIO chip it doesn't
> >> seem to be working. How do I get this working, I haven't found
> >> any useful reference online and need some help:
> >>
> >> (qemu) qom-set /machine/peripheral/gpio unnamed-gpio-out[0] 0
> >> Error: Device '0' not found
> >> (qemu) qom-set /machine/peripheral/gpio unnamed-gpio-in[0] 0
> >> Error: Insufficient permission to perform this operation
> >
> > The 'unnamed-gpio-out/in' properties are part of the mechanism by
> > which a QEMU machine model can connect up GPIO lines of devices it
> > creates (for instance, it might connect a device's outbound GPIO
> > line to a GPIO controller). They appear in the monitor
> > qom-set/qom-get APIs because they use the same underlying
> > infrastructure as user-settable properties, but you can't do
> > anything useful with them on the command line.
> >
> > If you need to wire up a device's GPIO lines, you need to do
> > it in C code as part of the QEMU machine model implementation.
> > Put another way,
> >    -device max7310,id=gpio,address=0x20
> > will work fine for "put a gpio controller at this i2c address,
> > so that guests that expect to be able to talk to one there
> > don't crash". You can't however actually wire up any of that
> > controller's GPIO lines to anything (emulated LEDs, other
> > devices, etc, etc).
>
> Ok, thanks.
>
> I was really trying to do something simple. I want to add the
> GPIO chip and just control the lines from an external script
> as part of a testing environment where the test framework can
> change a GPIO value and the configuration in the machine will
> notice this and take appropriate actions.
>
> Is it worth adding some mechanism to allow the command line to
> specify how gpios are created, or have an option to just export
> all the GPIO lines as generic GPIOs? I'll have to go see how
> much effort it would be to make our own machine file.
>
> >> I am also having issues with both sensor and the gpio via the
> >> qom-set, as so:
> >>
> >>> $ sudo ./scripts/qmp/qom-set --socket ~/qmp.sock 
> >>> /machine/peripheral/sensor.temperature 20200
> >>> ExecuteError: Invalid parameter type for 'temperature', expected: integer
> >>> Task was destroyed but it is pending!
> >>
> >> Is this also a known issue?
> >
> > I'm not sure what's going on there: it sounds like something
> > is confused about types. I've cc'd the python qmp scripts maintainer.
> >

Howdy. The qom-set and qom-get tools have been around for quite a
while longer than I have been taking care of them, and I wasn't sure
if anyone was actually using them...

They *do* have a defect where they assume anything you enter is a
string and they send it that way over the wire. If the argument you
are sending actually requires an integer, it's going to fail. I had a
discussion recently on how we might be able to fix this, but since QOM
data is ... semi-opaque and incomplete at times, there's no real way
to know the correct type in advance.

If it would help people out, I could change the way the scripts work
to place the burden on the human user, i.e.

> qom-set \"20200\"
> qom-set 20200

would become explicitly different invocations. I really genuinely have
no clue if anyone is relying on this script though, so I've been
afraid to really do much with it. Maybe breaking some users of this
script in order to prevent new users from learning it doesn't really
work is a fine trade-off, though.

--js