From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
Halil Pasic <pasic@linux.ibm.com>,
Jason Herne <jjherne@linux.ibm.com>,
Jared Rossi <jrossi@linux.ibm.com>
Subject: Re: [PATCH v3 0/8] s390x/vfio-ccw: Channel Path Handling [KVM]
Date: Wed, 22 Apr 2020 12:27:46 +0200 [thread overview]
Message-ID: <20200422122746.33c53ee3.cohuck@redhat.com> (raw)
In-Reply-To: <8acd4662-5a8b-ceda-108f-ed2cfac8dcee@linux.ibm.com>
On Tue, 21 Apr 2020 23:10:20 -0400
Eric Farman <farman@linux.ibm.com> wrote:
> On 4/21/20 11:35 AM, Cornelia Huck wrote:
> > On Fri, 17 Apr 2020 04:29:53 +0200
> > Eric Farman <farman@linux.ibm.com> wrote:
> >
> >> Here is a new pass at the channel-path handling code for vfio-ccw.
> >> Changes from previous versions are recorded in git notes for each patch.
> >>
> >> I dropped the "Remove inline get_schid()" patch from this version.
> >> When I made the change suggested in v2, it seemed rather frivolous and
> >> better to just drop it for the time being.
> >>
> >> I suspect that patches 5 and 7 would be better squashed together, but I
> >> have not done that here. For future versions, I guess.
> >
> > The result also might get a bit large.
>
> True.
>
> Not that someone would pick patch 5 and not 7, but vfio-ccw is broken
> between them, because of a mismatch in IRQs. An example from hotplug:
>
> error: internal error: unable to execute QEMU command 'device_add':
> vfio: unexpected number of irqs 1
>
> Maybe I just pull the CRW_IRQ definition into 5, and leave the wiring of
> the CRW stuff in 7. That seems to leave a better behavior.
Ok, that makes sense.
>
> >
> >>
> >> With this, and the corresponding QEMU series (to be posted momentarily),
> >> applied I am able to configure off/on a CHPID (for example, by issuing
> >> "chchp -c 0/1 xx" on the host), and the guest is able to see both the
> >> events and reflect the updated path masks in its structures.
> >
> > Basically, this looks good to me (modulo my comments).
>
> Woo! Thanks for the feedback; I'm going to try to get them all
> addressed in the next couple of days.
>
> >
> > One thing though that keeps coming up: do we need any kind of
> > serialization? Can there be any confusion from concurrent reads from
> > userspace, or are we sure that we always provide consistent data?
> >
>
> I'm feeling better with the rearrangement in this version of how we get
> data from the queue of CRWs into the region and off to the guest. The
> weirdness I described a few months ago seems to have been triggered by
> one of the patches that's now been dropped. But I'll walk through this
> code again once I get your latest comments applied.
Ok. Might also be nice if somebody else could spend some cycles looking
at this (hint, hint :)
prev parent reply other threads:[~2020-04-22 10:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 2:29 [PATCH v3 0/8] s390x/vfio-ccw: Channel Path Handling [KVM] Eric Farman
2020-04-17 2:29 ` [PATCH v3 1/8] vfio-ccw: Introduce new helper functions to free/destroy regions Eric Farman
2020-04-17 2:29 ` [PATCH v3 2/8] vfio-ccw: Register a chp_event callback for vfio-ccw Eric Farman
2020-04-17 10:29 ` Cornelia Huck
2020-04-17 12:38 ` Eric Farman
2020-04-17 2:29 ` [PATCH v3 3/8] vfio-ccw: Refactor the unregister of the async regions Eric Farman
2020-04-17 2:29 ` [PATCH v3 4/8] vfio-ccw: Introduce a new schib region Eric Farman
2020-04-21 9:24 ` Cornelia Huck
2020-04-17 2:29 ` [PATCH v3 5/8] vfio-ccw: Introduce a new CRW region Eric Farman
2020-04-21 9:41 ` Cornelia Huck
2020-04-21 11:02 ` Eric Farman
2020-04-21 11:08 ` Cornelia Huck
2020-04-21 12:03 ` Eric Farman
2020-04-17 2:29 ` [PATCH v3 6/8] vfio-ccw: Refactor IRQ handlers Eric Farman
2020-04-17 2:30 ` [PATCH v3 7/8] vfio-ccw: Wire up the CRW irq and CRW region Eric Farman
2020-04-21 12:06 ` Cornelia Huck
2020-04-17 2:30 ` [PATCH v3 8/8] vfio-ccw: Add trace for CRW event Eric Farman
2020-04-21 12:11 ` Cornelia Huck
2020-04-21 15:35 ` [PATCH v3 0/8] s390x/vfio-ccw: Channel Path Handling [KVM] Cornelia Huck
2020-04-22 3:10 ` Eric Farman
2020-04-22 10:27 ` Cornelia Huck [this message]
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=20200422122746.33c53ee3.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=jrossi@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
/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).