From: Arnd Bergmann <arnd@arndb.de> To: "Wolfram Sang" <wsa@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>, "Jie Deng" <jie.deng@intel.com>, "Linux I2C" <linux-i2c@vger.kernel.org>, virtualization@lists.linux-foundation.org, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>, conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, "Sergey Semin" <Sergey.Semin@baikalelectronics.ru>, "Mike Rapoport" <rppt@kernel.org>, loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, yu1.wang@intel.com, shuo.a.liu@intel.com, "Viresh Kumar" <viresh.kumar@linaro.org>, "Stefan Hajnoczi" <stefanha@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com> Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Mon, 28 Jun 2021 13:50:53 +0200 [thread overview] Message-ID: <CAK8P3a3vD0CpuJW=3w3nq0h9HECCiOigNWK-SvXq=m1zZpqvjA@mail.gmail.com> (raw) In-Reply-To: <YNmg2IEpUlArZXPK@ninjato> On Mon, Jun 28, 2021 at 12:13 PM Wolfram Sang <wsa@kernel.org> wrote: > > > > Ok, that's what I thought. There is one corner case that I've struggled > > with though: Suppose the host has an SMBus-only driver, and the > > proposed driver exposes this as an I2C device to the guest, which > > makes it available to guest user space (or a guest kernel driver) > > using the emulated smbus command set. Is it always possible for > > the host user space to turn the I2C transaction back into the > > expected SMBus transaction on the host? > > If an SMBus commands gets converted to I2C messages, it can be converted > back to an SMBus command. I don't see anything preventing that right > now. However, the mapping-back code does look a bit clumsy, now that I > envision it. Maybe it is better, after all, to support I2C_SMBUS > directly and pass SMBus transactions as is. It should be a tad more > effiecient, too. You can fine Viresh's vhost-user implementation at https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.org/t/#m3b5044bad9769b170f505e63bd081eb27cef8db2 As you say, it does get a bit clumsy, but I think there is also a good argument to be made that the clumsiness is based on the host Linux user interface more than the on the requirements of the physical interface, and that should not have to be reflected in the virtio specification. > Speaking of it, I recall another gory detail: SMBus has transfers named > "read block data" and "block process call". These also need special > support from I2C host controllers before they can be emulated because > the length of the read needs to be adjusted in flight. These commands > are rare and not hard to implement. However, it makes exposing what is > supported a little more difficult. Right, this one has come up before as well: the preliminary result was to assume that this probably won't be needed, but would be easy enough to add later if necessary. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: "Wolfram Sang" <wsa@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>, "Jie Deng" <jie.deng@intel.com>, "Linux I2C" <linux-i2c@vger.kernel.org>, virtualization@lists.linux-foundation.org, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>, conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, "Sergey Semin" <Sergey.Semin@baikalelectronics.ru>, "Mike Rapoport" <rppt@kernel.org>, loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, yu1.wang@intel.com, shuo.a.liu@intel.com, "Viresh Kumar" <viresh.kumar@linaro.org>, "Stefan Hajnoczi" <stefanha@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com> Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Mon, 28 Jun 2021 13:50:53 +0200 [thread overview] Message-ID: <CAK8P3a3vD0CpuJW=3w3nq0h9HECCiOigNWK-SvXq=m1zZpqvjA@mail.gmail.com> (raw) In-Reply-To: <YNmg2IEpUlArZXPK@ninjato> On Mon, Jun 28, 2021 at 12:13 PM Wolfram Sang <wsa@kernel.org> wrote: > > > > Ok, that's what I thought. There is one corner case that I've struggled > > with though: Suppose the host has an SMBus-only driver, and the > > proposed driver exposes this as an I2C device to the guest, which > > makes it available to guest user space (or a guest kernel driver) > > using the emulated smbus command set. Is it always possible for > > the host user space to turn the I2C transaction back into the > > expected SMBus transaction on the host? > > If an SMBus commands gets converted to I2C messages, it can be converted > back to an SMBus command. I don't see anything preventing that right > now. However, the mapping-back code does look a bit clumsy, now that I > envision it. Maybe it is better, after all, to support I2C_SMBUS > directly and pass SMBus transactions as is. It should be a tad more > effiecient, too. You can fine Viresh's vhost-user implementation at https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.org/t/#m3b5044bad9769b170f505e63bd081eb27cef8db2 As you say, it does get a bit clumsy, but I think there is also a good argument to be made that the clumsiness is based on the host Linux user interface more than the on the requirements of the physical interface, and that should not have to be reflected in the virtio specification. > Speaking of it, I recall another gory detail: SMBus has transfers named > "read block data" and "block process call". These also need special > support from I2C host controllers before they can be emulated because > the length of the read needs to be adjusted in flight. These commands > are rare and not hard to implement. However, it makes exposing what is > supported a little more difficult. Right, this one has come up before as well: the preliminary result was to assume that this probably won't be needed, but would be easy enough to add later if necessary. Arnd _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-06-28 11:53 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-23 14:19 [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Jie Deng 2021-03-23 14:19 ` Jie Deng 2021-03-23 7:27 ` Viresh Kumar 2021-03-23 8:33 ` Jie Deng 2021-03-23 8:33 ` Jie Deng 2021-03-23 8:37 ` Viresh Kumar 2021-03-23 9:27 ` Arnd Bergmann 2021-03-23 9:27 ` Arnd Bergmann 2021-03-24 1:17 ` Jie Deng 2021-03-24 1:17 ` Jie Deng 2021-03-24 4:00 ` Viresh Kumar 2021-04-15 6:45 ` Viresh Kumar 2021-04-15 6:56 ` Jie Deng 2021-04-15 6:56 ` Jie Deng 2021-04-15 7:15 ` Viresh Kumar 2021-04-15 7:21 ` Wolfram Sang 2021-04-15 7:24 ` Viresh Kumar 2021-04-15 7:28 ` Wolfram Sang 2021-04-15 7:37 ` Viresh Kumar 2021-04-15 8:15 ` Jie Deng 2021-04-15 8:15 ` Jie Deng 2021-04-15 8:18 ` Wolfram Sang 2021-04-15 8:20 ` Jie Deng 2021-04-15 8:20 ` Jie Deng 2021-05-27 6:49 ` Jie Deng 2021-05-27 6:49 ` Jie Deng 2021-05-12 1:37 ` Jie Deng 2021-05-12 1:37 ` Jie Deng 2021-03-23 9:01 ` Viresh Kumar 2021-03-23 9:38 ` Viresh Kumar 2021-03-24 0:53 ` Jie Deng 2021-03-24 0:53 ` Jie Deng 2021-03-24 3:52 ` Viresh Kumar 2021-03-24 4:00 ` Jie Deng 2021-03-24 4:00 ` Jie Deng 2021-03-24 4:02 ` Viresh Kumar 2021-03-24 4:20 ` Viresh Kumar 2021-03-24 6:05 ` Jie Deng 2021-03-24 6:05 ` Jie Deng 2021-03-24 6:09 ` Viresh Kumar 2021-03-24 6:41 ` Jie Deng 2021-03-24 6:41 ` Jie Deng 2021-03-24 6:44 ` Viresh Kumar 2021-04-14 2:07 ` Jie Deng 2021-04-14 2:07 ` Jie Deng 2021-04-14 3:52 ` Viresh Kumar 2021-04-15 6:25 ` Jie Deng 2021-04-15 6:25 ` Jie Deng 2021-04-15 3:51 ` Jason Wang 2021-04-15 3:51 ` Jason Wang 2021-04-15 6:17 ` Jie Deng 2021-04-15 6:17 ` Jie Deng 2021-06-28 8:39 ` Wolfram Sang 2021-06-28 9:01 ` Arnd Bergmann 2021-06-28 9:01 ` Arnd Bergmann 2021-06-28 9:25 ` Wolfram Sang 2021-06-28 9:51 ` Arnd Bergmann 2021-06-28 9:51 ` Arnd Bergmann 2021-06-28 10:13 ` Wolfram Sang 2021-06-28 11:50 ` Arnd Bergmann [this message] 2021-06-28 11:50 ` Arnd Bergmann 2021-06-28 14:58 ` Wolfram Sang 2021-06-29 3:04 ` Jie Deng 2021-06-29 3:04 ` Jie Deng 2021-06-29 8:30 ` Wolfram Sang 2021-06-29 9:13 ` Viresh Kumar 2021-06-29 9:13 ` Viresh Kumar 2021-06-29 9:36 ` Wolfram Sang 2021-06-29 4:10 ` Viresh Kumar 2021-06-29 4:10 ` Viresh Kumar 2021-06-29 8:27 ` Wolfram Sang 2021-06-29 8:52 ` Viresh Kumar 2021-06-29 8:52 ` Viresh Kumar 2021-06-29 9:07 ` Wolfram Sang 2021-06-30 14:38 ` Wolfram Sang 2021-06-30 15:09 ` Viresh Kumar 2021-06-30 15:09 ` Viresh Kumar 2021-06-29 3:03 ` Jie Deng 2021-06-29 3:03 ` Jie Deng 2021-06-29 10:07 ` Wolfram Sang 2021-06-29 10:16 ` Viresh Kumar 2021-06-29 10:16 ` Viresh Kumar 2021-06-29 10:23 ` Wolfram Sang 2021-06-29 10:30 ` Viresh Kumar 2021-06-29 10:30 ` Viresh Kumar 2021-06-29 10:42 ` Wolfram Sang 2021-06-29 10:43 ` Wolfram Sang 2021-06-29 10:56 ` Viresh Kumar 2021-06-29 10:56 ` Viresh Kumar 2021-06-29 11:11 ` Wolfram Sang 2021-06-29 11:16 ` Viresh Kumar 2021-06-29 11:16 ` Viresh Kumar 2021-06-29 11:48 ` Wolfram Sang 2021-07-05 12:18 ` Viresh Kumar 2021-07-05 12:18 ` Viresh Kumar 2021-07-06 1:50 ` Jie Deng 2021-07-06 1:50 ` Jie Deng 2021-07-22 15:15 ` Wolfram Sang 2021-07-23 2:28 ` Viresh Kumar 2021-07-23 2:28 ` Viresh Kumar 2021-07-23 5:28 ` Viresh Kumar 2021-07-23 5:28 ` Viresh Kumar 2021-06-30 6:45 ` Jie Deng 2021-06-30 6:45 ` Jie Deng 2021-06-30 7:32 ` Wolfram Sang 2021-06-30 7:51 ` Jie Deng 2021-06-30 7:51 ` Jie Deng 2021-06-30 7:55 ` Arnd Bergmann 2021-06-30 7:55 ` Arnd Bergmann 2021-06-30 8:04 ` Wolfram Sang 2021-06-30 8:07 ` Andy Shevchenko 2021-06-30 8:07 ` Andy Shevchenko 2021-06-30 8:29 ` Arnd Bergmann 2021-06-30 8:29 ` Arnd Bergmann
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='CAK8P3a3vD0CpuJW=3w3nq0h9HECCiOigNWK-SvXq=m1zZpqvjA@mail.gmail.com' \ --to=arnd@arndb.de \ --cc=Sergey.Semin@baikalelectronics.ru \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bjorn.andersson@linaro.org \ --cc=conghui.chen@intel.com \ --cc=jarkko.nikula@linux.intel.com \ --cc=jasowang@redhat.com \ --cc=jie.deng@intel.com \ --cc=kblaiech@mellanox.com \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=loic.poulain@linaro.org \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=rppt@kernel.org \ --cc=shuo.a.liu@intel.com \ --cc=stefanha@redhat.com \ --cc=tali.perry1@gmail.com \ --cc=u.kleine-koenig@pengutronix.de \ --cc=viresh.kumar@linaro.org \ --cc=virtualization@lists.linux-foundation.org \ --cc=wsa@kernel.org \ --cc=yu1.wang@intel.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.