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
signature.asc
Description: PGP signature
