From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Pierre Morel <pmorel@linux.ibm.com>,
Farhan Ali <alifm@linux.ibm.com>,
Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4 2/2] vfio-ccw: support async command subregion
Date: Wed, 29 May 2019 11:48:28 +0200 [thread overview]
Message-ID: <20190529114828.046a832f.cohuck@redhat.com> (raw)
In-Reply-To: <192d35fa-12be-c840-e61c-716a3bd80943@linux.ibm.com>
On Tue, 21 May 2019 16:47:45 -0400
Eric Farman <farman@linux.ibm.com> wrote:
> On 5/21/19 12:32 PM, Cornelia Huck wrote:
> > Why mostly? I'm not sure yet whether we handling multiple requests for
> > passthrough devices correctly yet (virtual should be fine.)
> >
> > Start vs. (start|halt|clear) is fine, as the code checks whether
> > something is already pending before poking the kernel interface.
> > Likewise, halt vs. (start|halt|clear) is fine, as the code checks for
> > halt or clear and start and halt use different regions. The problematic
> > one is clear, as that's something that's always supposed to go through.
> > Probably fine if clear should always "win", but I need to think some
> > more about that.
>
> I suspect you are right, because of the check on the halt side, and
> considering that the clear is the biggest recovery action we have. So
> this does seem like things are okay. I'll ponder this overnight and
> finish my review tomorrow.
Ok, what's the verdict here? :)
(I'm trying to clean up my pending stuff :)
next prev parent reply other threads:[~2019-05-29 9:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 15:47 [Qemu-devel] [PATCH v4 0/2] vfio-ccw: support hsch/csch (QEMU part) Cornelia Huck
2019-05-07 15:47 ` [Qemu-devel] [PATCH v4 1/2] linux-headers: update Cornelia Huck
2019-05-07 15:47 ` [Qemu-devel] [PATCH v4 2/2] vfio-ccw: support async command subregion Cornelia Huck
2019-05-20 8:42 ` Cornelia Huck
2019-05-20 16:30 ` Eric Farman
2019-05-20 16:29 ` Eric Farman
2019-05-20 16:47 ` Cornelia Huck
2019-05-21 16:32 ` Cornelia Huck
2019-05-21 20:47 ` Eric Farman
2019-05-29 9:48 ` Cornelia Huck [this message]
2019-05-29 13:47 ` Eric Farman
2019-05-21 20:51 ` Farhan Ali
2019-05-22 10:13 ` Cornelia Huck
2019-05-21 20:50 ` Farhan Ali
2019-05-22 10:17 ` Cornelia Huck
2019-05-22 11:53 ` Farhan Ali
2019-05-29 13:47 ` Eric Farman
2019-05-31 12:42 ` 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=20190529114828.046a832f.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=farman@linux.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.