From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Morel Subject: Re: [PATCH v2 2/5] vfio-ccw: concurrent I/O handling Date: Thu, 24 Jan 2019 12:18:11 +0100 Message-ID: <639d520f-8a2a-3ffe-013a-26c172b712c0@linux.ibm.com> References: <20190121110354.2247-1-cohuck@redhat.com> <20190121110354.2247-3-cohuck@redhat.com> <20190122193346.4e23e018@oc2783563651> <20190123112112.7822b237.cohuck@redhat.com> <42264dd9-86d7-8994-8c25-bc688067725d@linux.ibm.com> <20190124111934.72e7f0f1.cohuck@redhat.com> Reply-To: pmorel@linux.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20190124111934.72e7f0f1.cohuck@redhat.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Archive: List-Post: To: Cornelia Huck Cc: linux-s390@vger.kernel.org, Eric Farman , kvm@vger.kernel.org, qemu-s390x@nongnu.org, Farhan Ali , qemu-devel@nongnu.org, Halil Pasic , Alex Williamson List-ID: On 24/01/2019 11:19, Cornelia Huck wrote: > On Thu, 24 Jan 2019 11:08:02 +0100 > Pierre Morel wrote: >=20 >> On 23/01/2019 11:21, Cornelia Huck wrote: >>> On Tue, 22 Jan 2019 19:33:46 +0100 >>> Halil Pasic wrote: >>> =20 >>>> On Mon, 21 Jan 2019 12:03:51 +0100 >>>> Cornelia Huck wrote: >>>> =20 >>>>> --- 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? >>> =20 >> >> 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 serie= s >> based on the last comment I got? >> >> I would take into account that the asynchronous commands will come wit= h >> your patch series and only provide the framework changes. >=20 > 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. >=20 > Does that sound reasonable? >=20 Absolutely, this was why I waited with my series. :) --=20 Pierre Morel Linux/KVM/QEMU in B=C3=B6blingen - Germany