OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.



Thanks,

Christian




Stefan



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]