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

[John Snow]

On Mon, Feb 28, 2022 at 6:44 AM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>
> On 25/02/2022 20:48, John Snow wrote:
> > 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.
>
> I would be happy with something like "qom-set ... integer:20000" or
> "qom-set ... -integer 20000".
>
> I am currently assuming the final integration of the work we're
> doing is going to be using python directly so that should work
> if it already knows what type of data is needed.
>
> Thanks for the reply.

Sure. If you want to use Python directly to send QMP commands back and
forth, look into using the QMP library to make custom-purpose scripts.
I'm mid-process in forking it out of the QEMU tree, so it'll be
available in a more official capacity. See
https://jsnow.gitlab.io/qemu.qmp/ -- but it's still early days there.

As for the qom-set/qom-get tools, I'll need to either deprecate them
or bolster them to become more actually useful. If you want to use
them for testing, I'd just advocate hacking them up to do what you
need to get moving an awful lot quicker.

--js