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


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

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

Subject: Re: [virtio-comment] Formal specification of virtIO

On Mon, Mar 09, 2020 at 04:03:34AM -0400, Michael S. Tsirkin wrote:
> On Sun, Nov 10, 2019 at 03:33:20PM +0100, Matias Vara wrote:
> > Hello everyone,
> > 
> > I have started to think of the formalization of the virtIO specification.
> > Roughly speaking, I could use a formal language to "code" the virtIO spec. As
> > far as I can think, this has three benefits: 
> > 1. You can validate any implementation.
> > 2. You can generate the implementation for a given target. For example, you
> > could be able to generate the implementation of a virtIO device in VHDL. 
> > 3. You can provide simulation and verification before any implementation. In
> > automotive, this is interesting because you ease the certification so
> > formalization pays off. 
> > 
> > Do you think this may be interesting work to do to become the virtIO
> > specification more robust? 
> > 
> > Regards, Matias.       
> I think the most intersting thing to model would be the virtqueue for
> systems with weak memory concurrency. Right now we have two virtqueue
> formats and getting concurrency right is the hardest part.  Having a
> formal model would be useful so we can extend the ring. Paul E.
> McKenney's talks gave me the impression that modeling any kind of weak
> memory concurrency is very challenging though.

Thanks Michael for your answer. Modeling weak memory concurrency sounds very challenging.
Other possible use of a model could be to verify that an implementation follows the
specification. To do so, the model must contain information information about how 
the driver and device shall behave, e.g., set DriverOK before initialize the virtqueues.
I think this may be easier to achieve. I do not know if this is interesting though.    

Regards, Matias.
> -- 

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