Re: [qemu-s390x] [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling

[Eric Farman]

On 01/24/2019 05:19 AM, Cornelia Huck wrote:
> On Thu, 24 Jan 2019 11:08:02 +0100
> Pierre Morel <address@hidden> wrote:
>
> > On 23/01/2019 11:21, Cornelia Huck wrote:
> > > On Tue, 22 Jan 2019 19:33:46 +0100
> > > Halil Pasic <address@hidden> wrote:
> > >    
> > > > On Mon, 21 Jan 2019 12:03:51 +0100
> > > > Cornelia Huck <address@hidden> wrote:
> > > >   
> > > > > --- a/drivers/s390/cio/vfio_ccw_private.h
> > > > > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > > > > @@ -28,6 +28,7 @@
> > > > >     * @mdev: pointer to the mediated device
> > > > >     * @nb: notifier for vfio events
> > > > >     * @io_region: MMIO region to input/output I/O arguments/results
> > > > > + * @io_mutex: protect against concurrent update of I/O structures
> > > >
> > > > We could be a bit more specific about what does this mutex guard.
> > > > Is it only io_region, or cp, irb and the new regions a well? ->state does
> > > > not seem to be covered, but should need some sort of synchronisation
> > > > too, or?
> > >
> > > I'm not sure. IIRC Pierre had some ideas about locking in the fsm?
> > >    
> >
> > Yes I postponed this work to not collide with your patch series.
> >
> > Do you think I should provide a new version of the FSM reworking series
> > based on the last comment I got?
> >
> > I would take into account that the asynchronous commands will come with
> > your patch series and only provide the framework changes.
>
> This was more an answer to Halil's concerns around state
> synchronization. I would prefer to first get this series (or a
> variation) into decent shape, and then address state machine handling
> on top of that (when we know more about the transitions involved), just
> to avoid confusion.
>
> Does that sound reasonable?

It does to me.

<Sorry for my silence; we teach our daughter to share, and she shares 
whatever bug is passed around daycare.  I'm catching up on my "todo" 
emails now!>