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

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]