All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Eric Farman <farman@linux.ibm.com>, Halil Pasic <pasic@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Vineeth Vijayan <vneethv@linux.ibm.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v1 10/16] vfio/ccw: refactor the idaw counter
Date: Mon, 19 Dec 2022 14:40:51 -0500	[thread overview]
Message-ID: <bd8545ae-c44b-b231-7cd6-71c8586d195d@linux.ibm.com> (raw)
In-Reply-To: <7f898d8a9dcf73d70f2f99377549ae9ad3b98527.camel@linux.ibm.com>

On 12/19/22 2:31 PM, Eric Farman wrote:
> On Mon, 2022-12-19 at 14:16 -0500, Matthew Rosato wrote:
>> On 11/21/22 4:40 PM, Eric Farman wrote:
>>> The rules of an IDAW are fairly simple: Each one can move no
>>> more than a defined amount of data, must not cross the
>>> boundary defined by that length, and must be aligned to that
>>> length as well. The first IDAW in a list is special, in that
>>> it does not need to adhere to that alignment, but the other
>>> rules still apply. Thus, by reading the first IDAW in a list,
>>> the number of IDAWs that will comprise a data transfer of a
>>> particular size can be calculated.
>>>
>>> Let's factor out the reading of that first IDAW with the
>>> logic that calculates the length of the list, to simplify
>>> the rest of the routine that handles the individual IDAWs.
>>>
>>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
>>> ---
>>>  drivers/s390/cio/vfio_ccw_cp.c | 39 ++++++++++++++++++++++++++----
>>> ----
>>>  1 file changed, 30 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/s390/cio/vfio_ccw_cp.c
>>> b/drivers/s390/cio/vfio_ccw_cp.c
>>> index a30f26962750..34a133d962d1 100644
>>> --- a/drivers/s390/cio/vfio_ccw_cp.c
>>> +++ b/drivers/s390/cio/vfio_ccw_cp.c
>>> @@ -496,23 +496,25 @@ static int ccwchain_fetch_tic(struct ccw1
>>> *ccw,
>>>         return -EFAULT;
>>>  }
>>>  
>>> -static int ccwchain_fetch_ccw(struct ccw1 *ccw,
>>> -                             struct page_array *pa,
>>> -                             struct channel_program *cp)
>>> +/*
>>> + * ccw_count_idaws() - Calculate the number of IDAWs needed to
>>> transfer
>>> + * a specified amount of data
>>> + *
>>> + * @ccw: The Channel Command Word being translated
>>> + * @cp: Channel Program being processed
>>> + */
>>> +static int ccw_count_idaws(struct ccw1 *ccw,
>>> +                          struct channel_program *cp)
>>>  {
>>>         struct vfio_device *vdev =
>>>                 &container_of(cp, struct vfio_ccw_private, cp)-
>>>> vdev;
>>>         u64 iova;
>>> -       unsigned long *idaws;
>>>         int ret;
>>>         int bytes = 1;
>>> -       int idaw_nr, idal_len;
>>> -       int i;
>>>  
>>>         if (ccw->count)
>>>                 bytes = ccw->count;
>>>  
>>> -       /* Calculate size of IDAL */
>>>         if (ccw_is_idal(ccw)) {
>>>                 /* Read first IDAW to see if it's 4K-aligned or
>>> not. */
>>>                 /* All subsequent IDAws will be 4K-aligned. */
>>> @@ -522,7 +524,26 @@ static int ccwchain_fetch_ccw(struct ccw1
>>> *ccw,
>>>         } else {
>>>                 iova = ccw->cda;
>>>         }
>>> -       idaw_nr = idal_nr_words((void *)iova, bytes);
>>> +
>>> +       return idal_nr_words((void *)iova, bytes);
>>> +}
>>> +
>>> +static int ccwchain_fetch_ccw(struct ccw1 *ccw,
>>> +                             struct page_array *pa,
>>> +                             struct channel_program *cp)
>>> +{
>>> +       struct vfio_device *vdev =
>>> +               &container_of(cp, struct vfio_ccw_private, cp)-
>>>> vdev;
>>> +       unsigned long *idaws;
>>> +       int ret;
>>> +       int idaw_nr, idal_len;
>>> +       int i;
>>> +
>>> +       /* Calculate size of IDAL */
>>> +       idaw_nr = ccw_count_idaws(ccw, cp);
>>> +       if (idaw_nr < 0)
>>> +               return idaw_nr;
>>> +
>>
>> What about if we get a 0 back from ccw_count_idaws?   The next thing
>> we're going to do (not shown here) is kcalloc(0, sizeof(*idaws)),
>> which I think means you'll get back ZERO_SIZE_PTR, not a null
>> pointer.
> 
> While it's true that the idal_nr_words routines could return zero, I
> don't see how the ccw_count_idaws routine which calls it could do the
> same. We added a check for a zero data count with commit 453eac312445e
> ("s390/cio: Allow zero-length CCWs in vfio-ccw"), such that a CCW that
> has no length will cause us to allocate -something- that would be valid
> for the channel to use, even if it's not going to put anything in/out
> of it.

Ah, yeah I was specifically looking at idal_nr_words and I missed the 'int bytes = 1;' business at the top of ccw_count_idaws. 

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

> 
>>
>>>         idal_len = idaw_nr * sizeof(*idaws);
>>>  
>>>         /* Allocate an IDAL from host storage */
>>> @@ -555,7 +576,7 @@ static int ccwchain_fetch_ccw(struct ccw1 *ccw,
>>>                 for (i = 0; i < idaw_nr; i++)
>>>                         pa->pa_iova[i] = idaws[i];
>>>         } else {
>>> -               pa->pa_iova[0] = iova;
>>> +               pa->pa_iova[0] = ccw->cda;
>>>                 for (i = 1; i < pa->pa_nr; i++)
>>>                         pa->pa_iova[i] = pa->pa_iova[i - 1] +
>>> PAGE_SIZE;
>>>         }
>>
> 


  reply	other threads:[~2022-12-19 19:41 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 21:40 [PATCH v1 00/16] vfio/ccw: channel program cleanup Eric Farman
2022-11-21 21:40 ` [PATCH v1 01/16] vfio/ccw: cleanup some of the mdev commentary Eric Farman
2022-11-22 16:12   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 02/16] vfio/ccw: simplify the cp_get_orb interface Eric Farman
2022-11-22 16:13   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 03/16] vfio/ccw: allow non-zero storage keys Eric Farman
2022-12-15 20:55   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 04/16] vfio/ccw: move where IDA flag is set in ORB Eric Farman
2022-12-15 20:55   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 05/16] vfio/ccw: replace copy_from_iova with vfio_dma_rw Eric Farman
2022-11-22  1:41   ` Jason Gunthorpe
2022-12-15 20:59   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 06/16] vfio/ccw: simplify CCW chain fetch routines Eric Farman
2022-12-15 21:18   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 07/16] vfio/ccw: remove unnecessary malloc alignment Eric Farman
2022-12-16 20:10   ` Matthew Rosato
2022-12-19 16:22     ` Eric Farman
2022-11-21 21:40 ` [PATCH v1 08/16] vfio/ccw: pass page count to page_array struct Eric Farman
2022-12-16 19:59   ` Matthew Rosato
2022-12-19 16:22     ` Eric Farman
2022-11-21 21:40 ` [PATCH v1 09/16] vfio/ccw: populate page_array struct inline Eric Farman
2022-12-16 21:05   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 10/16] vfio/ccw: refactor the idaw counter Eric Farman
2022-12-19 19:16   ` Matthew Rosato
2022-12-19 19:31     ` Eric Farman
2022-12-19 19:40       ` Matthew Rosato [this message]
2022-11-21 21:40 ` [PATCH v1 11/16] vfio/ccw: discard second fmt-1 IDAW Eric Farman
2022-12-19 19:27   ` Matthew Rosato
2022-12-19 20:27     ` Eric Farman
2022-11-21 21:40 ` [PATCH v1 12/16] vfio/ccw: calculate number of IDAWs regardless of format Eric Farman
2022-12-19 19:49   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 13/16] vfio/ccw: allocate/populate the guest idal Eric Farman
2022-12-19 20:14   ` Matthew Rosato
2022-12-19 21:00     ` Eric Farman
2022-11-21 21:40 ` [PATCH v1 14/16] vfio/ccw: handle a guest Format-1 IDAL Eric Farman
2022-12-19 20:29   ` Matthew Rosato
2022-12-19 21:04     ` Eric Farman
2022-11-21 21:40 ` [PATCH v1 15/16] vfio/ccw: don't group contiguous pages on 2K IDAWs Eric Farman
2022-12-19 20:40   ` Matthew Rosato
2022-11-21 21:40 ` [PATCH v1 16/16] vfio/ccw: remove old IDA format restrictions Eric Farman
2022-12-19 20:44   ` Matthew Rosato

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=bd8545ae-c44b-b231-7cd6-71c8586d195d@linux.ibm.com \
    --to=mjrosato@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=farman@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=vneethv@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 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.