On Tue, 9 Jun 2026 16:38:54 +0000 Tamás Király <[email protected]> wrote:
> Hi Jonathan, > > Thank you for responding to my email. You are right I was a little bit vague > with the topic, allow me to elaborate: > > My starting point for sensors is the sensor > hat<https://www.raspberrypi.com/products/sense-hat/> for Raspberry Pi. It > contains humidity, temperature, pressure, IMU, etc. so I am mainly talking > about embedded sensors which provide their stuff via I2C, SPI or similar > protocol. A lot of these sensors have kernel drivers thanks to the IIO > subsystem so the user side is pretty much done. > I think there is room for development on the sensor side, like replacing the > hardware with software temporarily for testing or other purposes. I can think > of a simulation which generates for example temperature measurements and > those are provided to the user (e.g. kernel driver) according to the BME280 > sensor's register mapping and datasheet. The goal here is that the kernel > driver (or generally the consumer of sensor output) does not see a difference > between real hardware and software simulation. > Always fascinated me that a piece of code was written assuming that it will > access a certain hardware and then I could swap that hardware with a software > component and see what happens. Is it depending on an undocumented hardware > behavior? Is it able to handle inconsistent sensor state? > > What do you think? Is this something worth looking into? Sensor emulation in general is fine, but I am a little unclear why vhost user is particularly valuable for this vs just emulating in tree. I've very little interest in any complex hardening against malicious or broken hardware. I don't mind such things in the kernel code if they are simple enough, but mostly this is considered out of scope because it bloats drivers for conditions we should never see. If you are interested in testing kernel drivers then there are lighter alternatives such as roadtest from axis. I gathered from a discussion at LPC that that might get reposted sometime soon as it has been out of tree for years. Quite a bit can also be done via the kernel selftesting environment these days. So on the whole extra sensor emulation in qemu is fine and useful for certain types of testing. Explain more on your thinking for using vhost for this. Jonathan > > Regards > Tamás > > ________________________________ > From: Jonathan Cameron <[email protected]> > Sent: Tuesday, June 9, 2026 16:42 > To: Tamás Király <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]> > Subject: Re: RFC sensor simulation in QEMU > > On Tue, 2 Jun 2026 13:23:14 +0000 > Tamás Király <[email protected]> wrote: > > > Hi all, > > > > I am interested in implementing sensor simulations. I already saw that > > there are some sensor implementations with varying details in QEMU. My > > question is the following: Is that a good idea to extend that part of QEMU > > or new implementations should happen outside of QEMU and some protocol, > > e.g. vhost user should be used to provide sensors to QEMU? I would like to > > align with the long term ideas. What was the original intent with the > > sensor subsystem? > > Hi Tamás > > 'Sensors' is a very broad term. Could you be a little more specific in what > types of sensors you are interested in? > > Thanks, > > Jonathan > > > > > regards > > Tamás Király >
