From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 170A6C2B9F4 for ; Mon, 28 Jun 2021 10:13:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF94261C69 for ; Mon, 28 Jun 2021 10:13:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232520AbhF1KQP (ORCPT ); Mon, 28 Jun 2021 06:16:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:53852 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231935AbhF1KQM (ORCPT ); Mon, 28 Jun 2021 06:16:12 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7840F61C67; Mon, 28 Jun 2021 10:13:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624875227; bh=xc6ZMpYRxnrW9nQ1Zq5NnDEAQ868wsvNoh+qThZ0uWg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mdAgPtX4+glgCpYKxdpoROB+RfkksJw93REfnY8VMxUSs7+qtxPqWF+IM2oR+uw4r sjFAYF9jpJKqVfiocmSPv28e5mULJkecwoXma7t1FGleVh6CXtaWAs/sDvEGqhQhsi tXWEosT1c+QpWggw9WukELj0wwRmpEk8y9j9OWYaiCXSKo2qfJqX5lPveUkg5OeKsM dgrB1siNlXOxcckHphrRnQnSu2MdZkjmzYQPYEHsMPP6h85dOsgGYv3qZ8KU4L1SWn 1UbrUFYiyJh4NKxpiFNVUhe2hSK8SdzXuoyUDvK0hnwi3grZ2xvDwpF/EDB632i+ff +qZ9HVsp3vccQ== Date: Mon, 28 Jun 2021 12:13:44 +0200 From: Wolfram Sang To: Arnd Bergmann Cc: Jie Deng , Linux I2C , virtualization@lists.linux-foundation.org, Linux Kernel Mailing List , "Michael S. Tsirkin" , Jason Wang , Andy Shevchenko , conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey Semin , Mike Rapoport , loic.poulain@linaro.org, Tali Perry , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Bjorn Andersson , yu1.wang@intel.com, shuo.a.liu@intel.com, Viresh Kumar , Stefan Hajnoczi , Paolo Bonzini Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Message-ID: Mail-Followup-To: Wolfram Sang , Arnd Bergmann , Jie Deng , Linux I2C , virtualization@lists.linux-foundation.org, Linux Kernel Mailing List , "Michael S. Tsirkin" , Jason Wang , Andy Shevchenko , conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey Semin , Mike Rapoport , loic.poulain@linaro.org, Tali Perry , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Bjorn Andersson , yu1.wang@intel.com, shuo.a.liu@intel.com, Viresh Kumar , Stefan Hajnoczi , Paolo Bonzini References: <226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.1616493817.git.jie.deng@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3gmtKsZb/eceSmxh" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --3gmtKsZb/eceSmxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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. 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. > 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. That sounds good. --3gmtKsZb/eceSmxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmDZoNMACgkQFA3kzBSg KbZeERAAlxLVin/Zmc6B+XbRcyhltAFcvOYutvLVeWSbLZ1iJ6ynsZlMmsxsgoHx 7eeljnSLAYGXS0Nqv3YEVSC6gx07139YQHyLhitc3sxo15PES8TAdr0caAHnJPN/ QLsYZhl/NDELoHtR+ULqfaFRu84XhFxmGp0Yb+7Q/p8F+JUalLSsFB3uAE2Blo/K YElcUrp+v6JdLV22J1dahQ1SvvQV/w922vJ9HeOlvbaVqxRSA8DvYyh48gDD8qXG SGRaFIHOiif7HtyiVFy7FVEDYoZyFRoOz/QpG6VxNfrqlbaSTkjk/kUhy01rp5hX yTQ5jm1bkE+2u2zc7XHHwqdzDb8WaT7r6C8dtA4LvDA44XDQ99vyUE//x23SnI73 PsY9Wyf4hbMwrZ9NC/CN9pZtLmRhSbSRKkoUSRdUj110Hk+iJZqHy9KuQfBgJey2 tpGYG5FC8kbMYKB0WrNpWQTTlHrCWRP8ULnhky1l7pqjsCLwIobMjC2mBk1uuqyZ Vhk8YM0yUTsq8VA5cNJXnMpHtvIYnGnQj9lH1V1cnJjPaUpg3ZzrGW9tmibaMLdp PnswWUWtSBv/kZZQQdqSY9zsTdpgQ6s6Dh0Lxyc7eAyL8UokFbRmlMkJx427jYWv 9Jzjro0d6MeoHZ116XtJ1zEZ3fLX4XPtZMr5LPvH2dNjbnTkqGY= =vBE7 -----END PGP SIGNATURE----- --3gmtKsZb/eceSmxh--