Hello Stefan, thanks for the feedback.I will rework the specification and send a v3 patch series.
Christian On Thu, Aug 4, 2016 at 10:46 AM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > On Fri, Jul 22, 2016 at 06:18:25PM +0200, Christian Pinto wrote: > > Hello Stefan, > > > > On Tue, Jul 19, 2016 at 10:40 AM, Stefan Hajnoczi <stefa...@redhat.com> > > wrote: > > > > > 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 > detail 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. 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? > > > > > > > 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. > > > > Does this sound in line with the virtio philosophy? > > > > 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 >
