From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVEIG-0000Xx-EG for qemu-devel@nongnu.org; Thu, 04 Aug 2016 04:46:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVEIC-00017d-D6 for qemu-devel@nongnu.org; Thu, 04 Aug 2016 04:46:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVEIC-00017Y-53 for qemu-devel@nongnu.org; Thu, 04 Aug 2016 04:46:16 -0400 Date: Thu, 4 Aug 2016 09:46:13 +0100 From: Stefan Hajnoczi Message-ID: <20160804084613.GA14185@stefanha-x1.localdomain> References: <1467111824-11548-1-git-send-email-c.pinto@virtualopensystems.com> <1467111824-11548-3-git-send-email-c.pinto@virtualopensystems.com> <20160714121702.GW15476@stefanha-x1.localdomain> <20160719084044.GC29459@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [virtio-dev][RFC v2 2/2] virtio-sdm: new device specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Pinto Cc: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org, Baptiste Reynal , Claudio Fontana , "qemu-devel@nongnu.org Developers" , Cornelia Huck , Jani Kokkonen , VirtualOpenSystems Technical Team --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 06:18:25PM +0200, Christian Pinto wrote: > Hello Stefan, >=20 > On Tue, Jul 19, 2016 at 10:40 AM, Stefan Hajnoczi > wrote: >=20 > > On Tue, Jul 19, 2016 at 09:47:13AM +0200, Christian Pinto wrote: > > > > > +During the initialization phase the device connects also to the > > > > communication > > > > > +channel. It has to be noted that the behavior of the device is > > > > > +independent from the communication channel used, that is a detai= l of > > > > each > > > > > +specific implementation of the SDM device. > > > > > > > > How are SDM devices identified? For example, if two SDM devices are > > > > available, how does the driver know which one serves a particular > > > > function? > > > > > > > > > > The master-slave role is supposed to be enough to identify the device= =2E If > > > as an example we consider an AMP system, the master core will only see > > one > > > SDM master device, while the slave processor will only see the slave = SDM > > > instance. Then it is up to the implementation of the drivers to define > > the > > > signals served, while the SDM hardware is only in charge of forwarding > > such > > > signals. We do not foresee the need to have one SDM instance for each > > > signal type. > > > > The laissez-faire approach of allowing the implementation to define > > signals breaks in an environment where there can be multiple versions of > > the SDM hardware. > > > > Virtio feature bits cannot be used to define signal-related > > functionality because it's implementation-defined. For example, there > > is no way to express "CUSTOM_SIGNAL_2 is supported". > > > > In a guest OS image that can run on two different types of AMP systems, > > how do you distinguish between the set of signals to use? > > > > I guess we can say that the driver has some external knowledge (e.g. the > > board/chipset type) that allows it to know the meaning of signals and > > which ones are available? > > >=20 > Here I see two possibilities either what you propose, to demand on an > external > knowledge of the driver on the implementation of the SDM device for the > specific board/chipset. Or alternatively we could think to embed the set = of > signals > supported by the implementation of the device in the configuration space. > We could univocally define signals in the specification of the device, > statically assigning each signal to an ID. > At devices initialization the driver reads the configuration and retrieves > the set of > signals supported. It is then up-to the user-level software to know the > semantic of each > signal (e.g., the meaning of the payload), that makes sense in my opinion. > We could also envision that at connection time between master and slave > there is > an handshake phase where the slave notifies the master with the set of > signals > it supports, and a slave can get rejected in case of mismatch. >=20 > Does this sound in line with the virtio philosophy? >=20 > Finally, the idea of the SDM is that in each deployment there is only one > master > and multiple slaves. I think the most satisfying approach from the VIRTIO spec perspective is to include the signals in the spec. That way feature bits can be used. Stefan --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXowDVAAoJEJykq7OBq3PIJyUH/RaUlAa9LNqS1Hy0YuRmt9bL /E4Mdk1y89coEp+l0rJHjcIM2EniP8W1F3yHtYpowwURa5vHWjp9z4dTNwy9zHlO ExMTt+H/t8CpWVCYPXalrI6yZgT1vZPwTLtX2KJQjKAhJJCf6C9KtTOLuC88bxVe JA97qjh53VzT5+krorQAykw5wQkYNITxlK4cJqbadj+QibLcRQqmtZ9S3y+puCvC Rj7Lgdhoh6JKJcerOTw5Uj00hYve1NQwk/5ndKB18JZ46tszP7g3J0d7GPoc07UE urUQYeNkXJWxY9QM6I3AiOH14QQwvnWpFXYi8Rm8kfgs8vYF847W4JDUdK8wgiE= =3B7T -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--