From: Eric Farman <farman@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.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: Tue, 21 Apr 2020 23:10:20 -0400 [thread overview]
Message-ID: <8acd4662-5a8b-ceda-108f-ed2cfac8dcee@linux.ibm.com> (raw)
In-Reply-To: <20200421173544.36b48657.cohuck@redhat.com>
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.
>
>>
>> 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.
next prev parent reply other threads:[~2020-04-22 3:10 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 [this message]
2020-04-22 10:27 ` 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=8acd4662-5a8b-ceda-108f-ed2cfac8dcee@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=cohuck@redhat.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).