From: Johannes Berg <johannes@sipsolutions.net> To: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: Brendan Higgins <brendanhiggins@google.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, kernel <kernel@axis.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-um@lists.infradead.org" <linux-um@lists.infradead.org>, "shuah@kernel.org" <shuah@kernel.org>, "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>, "jic23@kernel.org" <jic23@kernel.org>, "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "broonie@kernel.org" <broonie@kernel.org>, "a.zummo@towertech.it" <a.zummo@towertech.it>, "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>, "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>, "corbet@lwn.net" <corbet@lwn.net>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org> Subject: Re: [RFC v1 07/10] iio: light: opt3001: add roadtest Date: Tue, 29 Mar 2022 16:50:09 +0200 [thread overview] Message-ID: <5b39d572e619c812109af7a1b8028bfb8353efda.camel@sipsolutions.net> (raw) In-Reply-To: <20220329144319.GA4474@axis.com> On Tue, 2022-03-29 at 16:43 +0200, Vincent Whitchurch wrote: > > I'm aware of vhost-user, but AFAICS QEMU needs glue for each device type > to be able to actually hook up vhost-user implementations to the devices > it exposes to the guest via the virtio PCI device. See e.g. > hw/virtio/vhost-user-i2c-pci.c and hw/virtio/vhost-user-i2c.c in QEMU. Oh, I wasn't aware of that. > That is what I meant was missing for virtio-gpio, there seems to be an > in-progress patch set for that here though: > https://lore.kernel.org/all/cover.1641987128.git.viresh.kumar@linaro.org/ > > Similarly, glue for something like arch/um/drivers/virt-pci.c does not > exist in QEMU. > > Or perhaps you are implying that hw/virtio/vhost-user-i2c* in QEMU are > not strictly needed? I _thought_ that was the case, but honestly, that was just from reading about it, not looking at the code. Thinking about it though, I don't need special glue in UML, just passing the device ID on the command line? So not sure what they need the glue for. Looking at the code, it's not really much though? Not sure, I guess you need somebody more familiar with qemu here, sorry. > > Wohoo! This makes me very happy, finally somebody else who uses it :-) > > Yes, thanks for that feature, it works well to speed up tests and also > has a knack for triggering race conditions (the RTC use-after-free for > example). > > Time travel however sometimes triggers some WARN_ONs from the core > timekeeping code. I haven't seen them when running the test suites, but > they show up if the system under UML is idle for several (wall time) > seconds. I haven't had a chance to investigate it further though, but I > can dig up the splats if you are interested. Oh, I haven't seen that, and I'm pretty sure I've had systems idle for very long periods of time passing inside (think weeks) ... So yeah, if you have some splats (ideally with corresponding kernel configs), I'd be interested. johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net> To: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: Brendan Higgins <brendanhiggins@google.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, kernel <kernel@axis.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-um@lists.infradead.org" <linux-um@lists.infradead.org>, "shuah@kernel.org" <shuah@kernel.org>, "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>, "jic23@kernel.org" <jic23@kernel.org>, "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "broonie@kernel.org" <broonie@kernel.org>, "a.zummo@towertech.it" <a.zummo@towertech.it>, "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>, "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>, "corbet@lwn.net" <corbet@lwn.net>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org> Subject: Re: [RFC v1 07/10] iio: light: opt3001: add roadtest Date: Tue, 29 Mar 2022 16:50:09 +0200 [thread overview] Message-ID: <5b39d572e619c812109af7a1b8028bfb8353efda.camel@sipsolutions.net> (raw) In-Reply-To: <20220329144319.GA4474@axis.com> On Tue, 2022-03-29 at 16:43 +0200, Vincent Whitchurch wrote: > > I'm aware of vhost-user, but AFAICS QEMU needs glue for each device type > to be able to actually hook up vhost-user implementations to the devices > it exposes to the guest via the virtio PCI device. See e.g. > hw/virtio/vhost-user-i2c-pci.c and hw/virtio/vhost-user-i2c.c in QEMU. Oh, I wasn't aware of that. > That is what I meant was missing for virtio-gpio, there seems to be an > in-progress patch set for that here though: > https://lore.kernel.org/all/cover.1641987128.git.viresh.kumar@linaro.org/ > > Similarly, glue for something like arch/um/drivers/virt-pci.c does not > exist in QEMU. > > Or perhaps you are implying that hw/virtio/vhost-user-i2c* in QEMU are > not strictly needed? I _thought_ that was the case, but honestly, that was just from reading about it, not looking at the code. Thinking about it though, I don't need special glue in UML, just passing the device ID on the command line? So not sure what they need the glue for. Looking at the code, it's not really much though? Not sure, I guess you need somebody more familiar with qemu here, sorry. > > Wohoo! This makes me very happy, finally somebody else who uses it :-) > > Yes, thanks for that feature, it works well to speed up tests and also > has a knack for triggering race conditions (the RTC use-after-free for > example). > > Time travel however sometimes triggers some WARN_ONs from the core > timekeeping code. I haven't seen them when running the test suites, but > they show up if the system under UML is idle for several (wall time) > seconds. I haven't had a chance to investigate it further though, but I > can dig up the splats if you are interested. Oh, I haven't seen that, and I'm pretty sure I've had systems idle for very long periods of time passing inside (think weeks) ... So yeah, if you have some splats (ideally with corresponding kernel configs), I'd be interested. johannes _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2022-03-29 14:50 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-11 16:24 [RFC v1 00/10] roadtest: a driver testing framework Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 01/10] roadtest: import libvhost-user from QEMU Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-24 13:00 ` Johannes Berg 2022-03-24 13:00 ` Johannes Berg 2022-04-05 13:54 ` Vincent Whitchurch 2022-04-05 13:54 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 02/10] roadtest: add C backend Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 03/10] roadtest: add framework Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 04/10] roadtest: add base config Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 05/10] roadtest: add build files Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 06/10] roadtest: add documentation Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 07/10] iio: light: opt3001: add roadtest Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-14 23:11 ` Brendan Higgins 2022-03-14 23:11 ` Brendan Higgins 2022-03-18 15:49 ` Vincent Whitchurch 2022-03-18 15:49 ` Vincent Whitchurch 2022-03-18 20:09 ` Johannes Berg 2022-03-18 20:09 ` Johannes Berg 2022-03-29 14:43 ` Vincent Whitchurch 2022-03-29 14:43 ` Vincent Whitchurch 2022-03-29 14:50 ` Johannes Berg [this message] 2022-03-29 14:50 ` Johannes Berg 2022-03-29 14:52 ` Johannes Berg 2022-03-29 14:52 ` Johannes Berg 2022-03-11 16:24 ` [RFC v1 08/10] iio: light: vcnl4000: " Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-20 17:02 ` Jonathan Cameron 2022-03-20 17:02 ` Jonathan Cameron 2022-04-05 13:48 ` Vincent Whitchurch 2022-04-05 13:48 ` Vincent Whitchurch 2022-04-06 13:08 ` Jonathan Cameron 2022-04-06 13:08 ` Jonathan Cameron 2022-04-14 10:20 ` Vincent Whitchurch 2022-04-14 10:20 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 09/10] regulator: tps62864: " Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-11 18:06 ` Mark Brown 2022-03-11 18:06 ` Mark Brown 2022-03-17 15:13 ` Vincent Whitchurch 2022-03-17 15:13 ` Vincent Whitchurch 2022-03-17 17:53 ` Mark Brown 2022-03-17 17:53 ` Mark Brown 2022-04-05 14:02 ` Vincent Whitchurch 2022-04-05 14:02 ` Vincent Whitchurch 2022-03-11 16:24 ` [RFC v1 10/10] rtc: pcf8563: " Vincent Whitchurch 2022-03-11 16:24 ` Vincent Whitchurch 2022-03-14 22:24 ` [RFC v1 00/10] roadtest: a driver testing framework Brendan Higgins 2022-03-14 22:24 ` Brendan Higgins 2022-03-17 16:09 ` Vincent Whitchurch 2022-03-17 16:09 ` Vincent Whitchurch 2022-04-18 19:44 ` Jonathan Cameron 2022-04-18 19:44 ` Jonathan Cameron
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5b39d572e619c812109af7a1b8028bfb8353efda.camel@sipsolutions.net \ --to=johannes@sipsolutions.net \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=brendanhiggins@google.com \ --cc=broonie@kernel.org \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=jic23@kernel.org \ --cc=kernel@axis.com \ --cc=lgirdwood@gmail.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-iio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-rtc@vger.kernel.org \ --cc=linux-um@lists.infradead.org \ --cc=shuah@kernel.org \ --cc=vincent.whitchurch@axis.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.