All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Dong Jia Shi <bjsdjshi@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, qemu-s390x@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH RFC 1/2] vfio-ccw: forward halt/clear to device if supported
Date: Wed, 16 May 2018 17:52:43 +0200	[thread overview]
Message-ID: <20180516175243.2ec79883.cohuck@redhat.com> (raw)
In-Reply-To: <57a7b9b1-130a-3c78-6e29-226f544c69c9@linux.ibm.com>

On Wed, 16 May 2018 15:53:48 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:

> On 15/05/2018 18:01, Cornelia Huck wrote:
> > On Fri, 11 May 2018 11:53:52 +0200
> > Pierre Morel <pmorel@linux.ibm.com> wrote:

> >> Couldn't we introduce ABI versioning ?  
> > Can you elaborate what you're referring to?
> >
> > If you mean checking capabilities of the kernel or so: If we can avoid
> > that and just try (and stop if it does not work), I'd prefer that (no
> > dependencies).  
> 
> VFIO_CHECK_EXTENSION is already used in different drivers
> for this kind of interface extension.
> We could use it to setup appropriate callbacks for scsh/csch/xsch/hsch
> depending on the extension argument.

Hm, this might be useful for things like xsch that aren't really well
served by the current interface. Or we could try using the
device-specific capability interface.

Let me think and play with this a bit.

WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Dong Jia Shi <bjsdjshi@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, qemu-s390x@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 1/2] vfio-ccw: forward halt/clear to device if supported
Date: Wed, 16 May 2018 17:52:43 +0200	[thread overview]
Message-ID: <20180516175243.2ec79883.cohuck@redhat.com> (raw)
In-Reply-To: <57a7b9b1-130a-3c78-6e29-226f544c69c9@linux.ibm.com>

On Wed, 16 May 2018 15:53:48 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:

> On 15/05/2018 18:01, Cornelia Huck wrote:
> > On Fri, 11 May 2018 11:53:52 +0200
> > Pierre Morel <pmorel@linux.ibm.com> wrote:

> >> Couldn't we introduce ABI versioning ?  
> > Can you elaborate what you're referring to?
> >
> > If you mean checking capabilities of the kernel or so: If we can avoid
> > that and just try (and stop if it does not work), I'd prefer that (no
> > dependencies).  
> 
> VFIO_CHECK_EXTENSION is already used in different drivers
> for this kind of interface extension.
> We could use it to setup appropriate callbacks for scsh/csch/xsch/hsch
> depending on the extension argument.

Hm, this might be useful for things like xsch that aren't really well
served by the current interface. Or we could try using the
device-specific capability interface.

Let me think and play with this a bit.

  reply	other threads:[~2018-05-16 15:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 15:49 [PATCH RFC 0/2] vfio-ccw: exploit halt/clear subchannel support Cornelia Huck
2018-05-09 15:49 ` [Qemu-devel] " Cornelia Huck
2018-05-09 15:49 ` [PATCH RFC 1/2] vfio-ccw: forward halt/clear to device if supported Cornelia Huck
2018-05-09 15:49   ` [Qemu-devel] " Cornelia Huck
2018-05-11  9:53   ` Pierre Morel
2018-05-11  9:53     ` [Qemu-devel] " Pierre Morel
2018-05-15 16:01     ` Cornelia Huck
2018-05-15 16:01       ` [Qemu-devel] " Cornelia Huck
2018-05-16 13:53       ` Pierre Morel
2018-05-16 13:53         ` [Qemu-devel] " Pierre Morel
2018-05-16 15:52         ` Cornelia Huck [this message]
2018-05-16 15:52           ` Cornelia Huck
2018-05-09 15:49 ` [PATCH RFC 2/2] s390/css: add some tracing for pass-through handling Cornelia Huck
2018-05-09 15:49   ` [Qemu-devel] " 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=20180516175243.2ec79883.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@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 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.