From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Eric Farman <farman@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH RFC UNTESTED] vfio-ccw: indirect access to translated cps
Date: Fri, 16 Aug 2019 00:34:02 +0200 [thread overview]
Message-ID: <20190816003402.2a52b863.pasic@linux.ibm.com> (raw)
In-Reply-To: <20190808104306.2450bdcf.cohuck@redhat.com>
On Thu, 8 Aug 2019 10:43:06 +0200
Cornelia Huck <cohuck@redhat.com> wrote:
> On Wed, 7 Aug 2019 16:01:36 +0200
> Halil Pasic <pasic@linux.ibm.com> wrote:
[..]
> > A respin of what? If you mean Pierre's "vfio: ccw: Make FSM functions
> > atomic" (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1711466.html)
> > that won't work any more because of async.
>
> s/respin/rework/, more likely.
Nod.
>
> >
> > > >
> > > > Besides the only point of converting cp to a pointer seems to be
> > > > policing access to cp_area (which used to be cp). I.e. if it is
> > > > NULL: don't touch it, otherwise: go ahead. We can do that with a single
> > > > bit, we don't need a pointer for that.
> > >
> > > The idea was
> > > - do translation etc. on an area only accessed by the thread doing the
> > > translation
> > > - switch the pointer to that area once the cp has been submitted
> > > successfully (and it is therefore associated with further interrupts
> > > etc.)
> > > The approach in this patch is probably a bit simplistic.
> > >
> > > I think one bit is not enough, we have at least three states:
> > > - idle; start using the area if you like
> > > - translating; i.e. only the translator is touching the area, keep off
> > > - submitted; we wait for interrupts, handle them or free if no (more)
> > > interrupts can happen
> >
> > I think your patch assigns the pointer when transitioning from
> > translated --> submitted. That can be tracked with a single bit, that's
> > what I was trying to say. You seem to have misunderstood: I never
> > intended to claim that a single bit is sufficient to get this clean (only
> > to accomplish what the pointer accomplishes -- modulo races).
> >
> > My impression was that the 'initialized' field is abut the idle -->
> > translating transition, but I never fully understood this 'initialized'
> > patch.
>
> So we do have three states here, right? (I hope we're not talking past
> each other again...)
Right, AFAIR and without any consideration to fine details the three
states and two state transitions do make sense.
>
> >
> > >
> > > >
> > > > Could we convert initialized into some sort of cp.status that
> > > > tracks/controls access and responsibilities? By working with bits we
> > > > could benefit from the atomicity of bit-ops -- if I'm not wrong.
> > >
> > > We have both the state of the device (state machine) and the state of a
> > > cp, then. If we keep to a single cp area, we should track that within a
> > > single state (i.e. the device state).
> > >
> >
> > Maybe. Maybe not. I would have to write or see the code to figure that
> > out. Would we need additional states introduced to the device (state
> > machine)?
>
> We might, but I don't think so. My point is that we probably want to
> track on a device level and not introduce extra tracking.
>
OK
> >
> > Anyway we do need to fix the races in the device state machine
> > for sure. I've already provided some food for thought (in form of a draft
> > patch) to Eric.
>
> Any chance you could post that patch? :)
>
Unfortunately I don't have the bandwidth to make a proper patch out of
it. The interactions are quite complex and it would take quite some time
to reach the point where I can say everything feels water-proof and
clean (inclusive testing). But since you seem curious about it I will
send you my draft work.
[..]
> >
> > TL;DR I don't think having two cp areas make sense.
>
> Let's stop going down that way further, I agree.
>
Great!
Regards,
Halil
next prev parent reply other threads:[~2019-08-15 22:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 10:06 [PATCH RFC UNTESTED] vfio-ccw: indirect access to translated cps Cornelia Huck
2019-07-30 15:49 ` Halil Pasic
2019-08-07 11:23 ` Cornelia Huck
2019-08-07 14:01 ` Halil Pasic
2019-08-08 8:43 ` Cornelia Huck
2019-08-15 22:34 ` Halil Pasic [this message]
2019-08-16 18:21 ` Eric Farman
2019-08-28 12:39 ` Cornelia Huck
2019-08-29 17:41 ` Halil Pasic
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=20190816003402.2a52b863.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.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).