qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: Eric Farman <farman@linux.ibm.com>,
	Farhan Ali <alifm@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	Alex Williamson <alex.williamson@redhat.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling
Date: Wed, 23 Jan 2019 11:34:47 +0100	[thread overview]
Message-ID: <20190123113447.04354ae4.cohuck@redhat.com> (raw)
In-Reply-To: <20190122200331.14ff2818@oc2783563651>

On Tue, 22 Jan 2019 20:03:31 +0100
Halil Pasic <pasic@linux.ibm.com> wrote:

> On Tue, 22 Jan 2019 18:26:17 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Tue, 22 Jan 2019 13:46:12 +0100
> > Halil Pasic <pasic@linux.ibm.com> wrote:

> > > Unsolicited interrupts are another
> > > piece of cake -- I have no idea how may of those do we get.  
> > 
> > They at least don't have the "free the cp before we got final state"
> > bug. But I think both are reasons to get away from "use the BUSY state
> > to ensure the right sequence".
> >   
> 
> I'm not sure I understand you correctly. I was under the impression that
> the whole point in having a state machine was to ensure the states are
> traversed in the right sequence with the right stuff being done on each
> transition. At least in theory.

Sequence in user space programs, not in the state machine.

> 
> You've probably figured out that IMHO vfio-ccw is not in a good shape
> (to put it mildly). I have a hard time reviewing a non-holistic
> concurrency fix. Please tell sould I get perceived as non-constructive,
> I will try to cut back on criticism. 

I'm afraid this is just confusing me :(

> 
> > > And because
> > > of this the broken sequencing in userspace could actually be the kernels
> > > fault.  
> > 
> > Here, I can't follow you at all :(
> >   
> 
> Should we ever deliver a zeroed out IRB to the userspace, for the next
> ioinst it would look like we have no status nor FC bit set. That is, the
> guest could end up with stuff in parallel that was never supposed to
> be in parallel (i.e. broken sequencing because kernel feeds false
> information due to race with unsolicited interrupt).
> 
> Does that help?

Not at all, I'm afraid :( User space programs still need to make sure
they poke the interfaces in the right order IMO...

At this point, I'm mostly confused... I'd prefer to simply fix things
as they come up so that we can finally move forward with the halt/clear
handling (and probably rework the state machine on top of that.)

  reply	other threads:[~2019-01-23 10:34 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 11:03 [Qemu-devel] [PATCH v2 0/5] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 1/5] vfio-ccw: make it safe to access channel programs Cornelia Huck
2019-01-22 14:56   ` Halil Pasic
2019-01-22 15:19     ` Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling Cornelia Huck
2019-01-21 20:20   ` Halil Pasic
2019-01-22 10:29     ` Cornelia Huck
2019-01-22 11:17       ` Halil Pasic
2019-01-22 11:53         ` Cornelia Huck
2019-01-22 12:46           ` Halil Pasic
2019-01-22 17:26             ` Cornelia Huck
2019-01-22 19:03               ` Halil Pasic
2019-01-23 10:34                 ` Cornelia Huck [this message]
2019-01-23 13:06                   ` Halil Pasic
2019-01-23 13:34                     ` Cornelia Huck
2019-01-24 19:16                       ` Eric Farman
2019-01-25 10:13                         ` Cornelia Huck
2019-01-22 18:33   ` Halil Pasic
2019-01-23 10:21     ` Cornelia Huck
2019-01-23 13:30       ` Halil Pasic
2019-01-24 10:05         ` Cornelia Huck
2019-01-24 10:08       ` Pierre Morel
2019-01-24 10:19         ` Cornelia Huck
2019-01-24 11:18           ` Pierre Morel
2019-01-24 11:45           ` Halil Pasic
2019-01-24 19:14           ` Eric Farman
2019-01-25  2:25   ` Eric Farman
2019-01-25  2:37     ` Eric Farman
2019-01-25 10:24       ` Cornelia Huck
2019-01-25 12:58         ` Cornelia Huck
2019-01-25 14:01           ` Halil Pasic
2019-01-25 14:21             ` Cornelia Huck
2019-01-25 16:04               ` Halil Pasic
2019-01-28 17:13                 ` Cornelia Huck
2019-01-28 19:30                   ` Halil Pasic
2019-01-29  9:58                     ` Cornelia Huck
2019-01-29 19:39                       ` Halil Pasic
2019-01-30 13:29                         ` Cornelia Huck
2019-01-30 14:32                           ` Farhan Ali
2019-01-28 17:09             ` Cornelia Huck
2019-01-28 19:15               ` Halil Pasic
2019-01-28 21:48                 ` Eric Farman
2019-01-29 10:20                   ` Cornelia Huck
2019-01-29 14:14                     ` Eric Farman
2019-01-29 18:53                       ` Cornelia Huck
2019-01-29 10:10                 ` Cornelia Huck
2019-01-25 15:57           ` Eric Farman
2019-01-28 17:24             ` Cornelia Huck
2019-01-28 21:50               ` Eric Farman
2019-01-25 20:22         ` Eric Farman
2019-01-28 17:31           ` Cornelia Huck
2019-01-25 13:09       ` Halil Pasic
2019-01-25 12:58     ` Halil Pasic
2019-01-25 20:21       ` Eric Farman
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 3/5] vfio-ccw: add capabilities chain Cornelia Huck
2019-01-23 15:57   ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2019-01-25 16:19   ` [Qemu-devel] " Eric Farman
2019-01-25 21:00     ` Eric Farman
2019-01-28 17:34       ` Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 4/5] s390/cio: export hsch to modules Cornelia Huck
2019-01-22 15:21   ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 5/5] vfio-ccw: add handling for async channel instructions Cornelia Huck
2019-01-23 15:51   ` Halil Pasic
2019-01-24 10:06     ` Cornelia Huck
2019-01-24 10:37       ` Halil Pasic
2019-01-25 21:00   ` Eric Farman
2019-01-28 17:40     ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190123113447.04354ae4.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=alifm@linux.ibm.com \
    --cc=farman@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).