All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason J. Herne" <jjherne@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: borntraeger@de.ibm.com, qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] s390x/event-facility: variable-length event masks
Date: Mon, 16 Oct 2017 13:11:19 -0400	[thread overview]
Message-ID: <bc948ac4-6efd-63e2-35e3-e7be6c656536@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171016154433.246fb264.cohuck@redhat.com>

On 10/16/2017 09:44 AM, Cornelia Huck wrote:
> On Wed, 11 Oct 2017 09:39:53 -0400
> "Jason J. Herne" <jjherne@linux.vnet.ibm.com> wrote:
>> ...
> 
> Out of curiousity: Do you have a guest that can verify this for mask
> lengths != 4? Given that the guest I wrote that one for back then is
> not publicly available...
> 

I do have a guest OS that exercises larger mask lengths. Nothing 
publicly available however.

>> ...
>>   static void write_event_mask(SCLPEventFacility *ef, SCCB *sccb)
>>   {
>>       WriteEventMask *we_mask = (WriteEventMask *) sccb;
>> +    uint16_t mask_length = be16_to_cpu(we_mask->mask_length);
>> +    uint32_t tmp_mask;
>>   
>> -    /* Attention: We assume that Linux uses 4-byte masks, what it actually
>> -       does. Architecture allows for masks of variable size, though */
>> -    if (be16_to_cpu(we_mask->mask_length) != 4) {
>> +    if (!mask_length || (mask_length > SCLP_EVENT_MASK_LEN_MAX)) {
>>           sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_MASK_LENGTH);
>>           goto out;
>>       }
>>   
>> +    /*
>> +     * Note: We currently only support masks up to 4 byte length;
>> +     *       the remainder is filled up with zeroes. Linux uses
>> +     *       a 4 byte mask length.
>> +     */
> 
> Do you have any plans for extending this? Or is there no need?
> 
> (I have to ask those questions, as the documentation is not publicly
> available...)
> 

As of right now 4B is all that is actually needed for any of the masks. 
The reason to allow for 32 byte requests is for guest operating systems 
who are already planning for the future. Someday more than 4B may be 
used but we have no way to know if or when.

>> ...
> 
> Patch looks reasonable as far as I can see (the documentation issue
> again...)
> 
> Did you need to change much from the original patch?
> 

Very little. Just a quick forward fit and test and all is well :)
Thanks for the original work. This saved me some time.

-- 
-- Jason J. Herne (jjherne@linux.vnet.ibm.com)

  reply	other threads:[~2017-10-16 17:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 13:39 [Qemu-devel] [PATCH] s390x/event-facility: variable-length event masks Jason J. Herne
2017-10-16 13:44 ` Cornelia Huck
2017-10-16 17:11   ` Jason J. Herne [this message]
2017-10-17  7:56     ` Cornelia Huck
2017-10-16 19:09 ` Christian Borntraeger
2017-10-17  7:57 ` 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=bc948ac4-6efd-63e2-35e3-e7be6c656536@linux.vnet.ibm.com \
    --to=jjherne@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.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.