Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.1616493817.git.jie.deng@intel.com>
 <YNmK0MP5ffQpiipt@ninjato> <CAK8P3a2qrfhyfZA-8qPVQ252tZXSBKVT==GigJMVvX5_XLPrCQ@mail.gmail.com>
 <YNmVg3ZhshshlbSx@ninjato>
In-Reply-To: <YNmVg3ZhshshlbSx@ninjato>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 28 Jun 2021 11:51:15 +0200
Message-ID: <CAK8P3a3Z-9MbsH6ZkXENZ-vt8+W5aP3t+EBcEGRmh2Cgr89R8Q@mail.gmail.com>
Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver
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>,
        =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= 
        <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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 28, 2021 at 11:25 AM Wolfram Sang <wsa@kernel.org> wrote:
> > 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.
>
> Correct. You need to pick I2C if you want to support all devices. SMBus
> will give you only a lot of devices.

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?

> > > 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.
>
> I am just thinking that a physical bus on the host may have devices that
> should be shared with the guest while other devices on the same bus
> should not be shared (PMIC!). I'd think this is a minimal requirement
> for security. I also wonder if it is possible to have a paravirtualized
> bus in the guest which has multiple devices from the host sitting on
> different physical busses there. But that may be the cherry on the top.

This is certainly possible, but is independent of the implementation of
the guest driver. It's up to the host to provision the devices that
are actually passed down to the guest, and this could in theory
be any combination of emulated devices with devices connected to
any of the host's physical buses. The host may also decide to remap
the addresses of the devices during passthrough.

       Arnd