All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] s390/cio: Refactor alloc of vfio_ccw_private
Date: Mon, 24 Sep 2018 09:21:51 +0000	[thread overview]
Message-ID: <20180924112151.4cabf94d.cohuck@redhat.com> (raw)
In-Reply-To: <62cd81fe-47e7-cf4e-67d4-39d1d2ebf1d1@linux.ibm.com>

On Fri, 21 Sep 2018 09:40:09 -0400
Eric Farman <farman@linux.ibm.com> wrote:

> On 09/21/2018 07:56 AM, Cornelia Huck wrote:
> > On Thu, 20 Sep 2018 17:19:34 +0200
> > Eric Farman <farman@linux.ibm.com> wrote:

> >> +	vfio_private_cache = kmem_cache_create_usercopy("vfio_ccw_private",
> >> +					sizeof(struct vfio_ccw_private),
> >> +					0, SLAB_ACCOUNT, IOREGION_OFFSET,
> >> +					IOREGION_SIZE, NULL);  
> > 
> > That should work fine, but I'm currently (...) trying to add more
> > regions (for example, for halt/clear handling) and I'm wondering
> > whether we should change how we allocate our I/O regions, for example
> > using a dedicated region that is pointed to by the private structure.
> > Thoughts?  
> 
> That would definitely make this a bit more future proof.  What would be 
> in the new regions, that's not in the ccw_io_region already?  (Which is 
> an orb and an irb, and for some reason another scsw).

The idea is not to include more data (at least for my current use
case), but rather to switch to a structure that allows user space to
specify a command (and sidestep the whole question about whether the
scsw is a real scsw etc.). We'll keep the existing region for ssch, but
I have something that is nearly ready that introduces a new structure
guarded by a capability chain that is used for handling hsch/csch (and
that I'll post if I ever find a spare minute.) Other possible uses are
path handling and other things.

           reply	other threads:[~2018-09-24  9:21 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <62cd81fe-47e7-cf4e-67d4-39d1d2ebf1d1@linux.ibm.com>]

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=20180924112151.4cabf94d.cohuck@redhat.com \
    --to=cohuck@redhat.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 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.