Re: [Qemu-devel] [virtio-dev][RFC v2 2/2] virtio-sdm: new device specification

[Christian Pinto <c.pinto@virtualopensystems.com>]

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 <stefanha@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 <stefanha@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
>