From: Arnd Bergmann <arnd@arndb.de> To: "Wolfram Sang" <wsa@kernel.org>, "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, "Arnd Bergmann" <arnd@arndb.de>, 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 11:01:41 +0200 [thread overview] Message-ID: <CAK8P3a2qrfhyfZA-8qPVQ252tZXSBKVT==GigJMVvX5_XLPrCQ@mail.gmail.com> (raw) In-Reply-To: <YNmK0MP5ffQpiipt@ninjato> On Mon, Jun 28, 2021 at 10:39 AM Wolfram Sang <wsa@kernel.org> wrote: > > sorry for the long delay. I am not familiar with VFIO, so I had to dive > into the topic a little first. I am still not seeing through it > completely, so I have very high-level questions first. You probably know this already, but just in case for clarification these are two different things: VFIO: kernel feature to make raw (usually PCI) devices available to user space drivers and virtual machines from a kernel running on bare metal. virtio: transport protocol for implementing arbitrary paravirtualized drivers in (usually) a virtual machine guest without giving the guest access to hardware registers. Both can be used for letting a KVM guest talk to the outside world, but usually you have one or the other, not both. > > The device specification can be found on > > https://lists.oasis-open.org/archives/virtio-comment/202101/msg00008.html. > > I think we need to start here: > > === > > If ``length of \field{read_buf}''=0 and ``length of \field{write_buf}''>0, > the request is called write request. > > If ``length of \field{read_buf}''>0 and ``length of \field{write_buf}''=0, > the request is called read request. > > If ``length of \field{read_buf}''>0 and ``length of \field{write_buf}''>0, > the request is called write-read request. It means an I2C write segment followed > by a read segment. Usually, the write segment provides the number of an I2C > controlled device register to be read. > > === > > I2C transactions can have an arbitrary number of messages which can > arbitrarily be read or write. As I understand the above, only one read, > write or read-write transaction is supported. If that is the case, it > would be not very much I2C but more SMBus. If my assumptions are true, > we first need to decide if you want to go the I2C way or SMBus subset. This has come up in previous reviews already. I think it comes down to the requirement that the virtio i2c protocol should allow passthrough access to any client devices connected to a physical i2c bus on the host, and this should ideally be independent of whether the host driver exposes I2C_RDWR or I2C_SMBUS ioctl interface, or both. This can be done either by having both interface types in the transport, or picking one of the two, and translating to the host interface type in software. As far as I understand me (please clarify), implementing only the smbus subset would mean that we cannot communicate with all client devices, while implementing both would add more complexity than the lower-level protocol. > === > > The case when ``length of \field{write_buf}''=0, and at the same time, > ``length of \field{read_buf}''=0 doesn't make any sense. > > === > > Oh, it does. That's a legal transfer, both in SMBus and I2C. It is used > to e.g. discover devices. I think it should be supported, even though > not all bus master drivers on the host can support it. Is it possible? > > Also, as I read it, a whole bus is para-virtualized to the guest, or? > Wouldn't it be better to allow just specific devices on a bus? Again, I > am kinda new to this, so I may have overlooked things. Do you mean just allowing a single device per bus (as opposed to having multiple devices as on a real bus), or just allowing a particular set of client devices that can be identified using virtio specific configuration (as opposed to relying on device tree or similar for probing). Both of these are valid questions that have been discussed before, but that could be revisited. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: "Wolfram Sang" <wsa@kernel.org>, "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, "Arnd Bergmann" <arnd@arndb.de>, 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 11:01:41 +0200 [thread overview] Message-ID: <CAK8P3a2qrfhyfZA-8qPVQ252tZXSBKVT==GigJMVvX5_XLPrCQ@mail.gmail.com> (raw) In-Reply-To: <YNmK0MP5ffQpiipt@ninjato> On Mon, Jun 28, 2021 at 10:39 AM Wolfram Sang <wsa@kernel.org> wrote: > > sorry for the long delay. I am not familiar with VFIO, so I had to dive > into the topic a little first. I am still not seeing through it > completely, so I have very high-level questions first. You probably know this already, but just in case for clarification these are two different things: VFIO: kernel feature to make raw (usually PCI) devices available to user space drivers and virtual machines from a kernel running on bare metal. virtio: transport protocol for implementing arbitrary paravirtualized drivers in (usually) a virtual machine guest without giving the guest access to hardware registers. Both can be used for letting a KVM guest talk to the outside world, but usually you have one or the other, not both. > > The device specification can be found on > > https://lists.oasis-open.org/archives/virtio-comment/202101/msg00008.html. > > I think we need to start here: > > === > > If ``length of \field{read_buf}''=0 and ``length of \field{write_buf}''>0, > the request is called write request. > > If ``length of \field{read_buf}''>0 and ``length of \field{write_buf}''=0, > the request is called read request. > > If ``length of \field{read_buf}''>0 and ``length of \field{write_buf}''>0, > the request is called write-read request. It means an I2C write segment followed > by a read segment. Usually, the write segment provides the number of an I2C > controlled device register to be read. > > === > > I2C transactions can have an arbitrary number of messages which can > arbitrarily be read or write. As I understand the above, only one read, > write or read-write transaction is supported. If that is the case, it > would be not very much I2C but more SMBus. If my assumptions are true, > we first need to decide if you want to go the I2C way or SMBus subset. This has come up in previous reviews already. I think it comes down to the requirement that the virtio i2c protocol should allow passthrough access to any client devices connected to a physical i2c bus on the host, and this should ideally be independent of whether the host driver exposes I2C_RDWR or I2C_SMBUS ioctl interface, or both. This can be done either by having both interface types in the transport, or picking one of the two, and translating to the host interface type in software. As far as I understand me (please clarify), implementing only the smbus subset would mean that we cannot communicate with all client devices, while implementing both would add more complexity than the lower-level protocol. > === > > The case when ``length of \field{write_buf}''=0, and at the same time, > ``length of \field{read_buf}''=0 doesn't make any sense. > > === > > Oh, it does. That's a legal transfer, both in SMBus and I2C. It is used > to e.g. discover devices. I think it should be supported, even though > not all bus master drivers on the host can support it. Is it possible? > > Also, as I read it, a whole bus is para-virtualized to the guest, or? > Wouldn't it be better to allow just specific devices on a bus? Again, I > am kinda new to this, so I may have overlooked things. Do you mean just allowing a single device per bus (as opposed to having multiple devices as on a real bus), or just allowing a particular set of client devices that can be identified using virtio specific configuration (as opposed to relying on device tree or similar for probing). Both of these are valid questions that have been discussed before, but that could be revisited. 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 9:04 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 [this message] 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 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='CAK8P3a2qrfhyfZA-8qPVQ252tZXSBKVT==GigJMVvX5_XLPrCQ@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.