From: Farhan Ali <email@example.com>
To: Eric Blake <firstname.lastname@example.org>, Cornelia Huck <email@example.com>,
Christian Borntraeger <firstname.lastname@example.org>,
Thomas Huth <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: Re: [Qemu-devel] [PATCH] s390-ccw: force diag 308 subcode to unsigned long
Date: Thu, 3 May 2018 12:03:18 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
On 05/03/2018 11:48 AM, Eric Blake wrote:
> On 05/03/2018 10:25 AM, Farhan Ali wrote:
>> On 05/02/2018 08:52 AM, Cornelia Huck wrote:
>>> We currently pass an integer as the subcode parameter. However,
>>> the upper bits of the register containing the subcode need to
>>> be 0, which is not guaranteed unless we explicitly specify the
>>> subcode to be an unsigned long value.
>>> Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag
>>> Signed-off-by: Cornelia Huck<firstname.lastname@example.org>
>> Sorry for my ignorance, but is there a C standard that says upper bits
>> of an int is not guaranteed to be 0?
> We're outside the bounds of the C standard because of the use of asm().
> The problem here is that the compiler assigning a 32-bit int into a
> 64-bit register uses the shortest sequence possible (leaving the upper
> 64 bits garbage), because the compiler assumes you correctly wrote the
> assembly to only use 32-bit operations on that register (which don't
> care about the upper bits). By using an unsigned long (a 64-bit value),
> the compiler instead emits assembly to write the full 64-bit register
> value, rather than leaving the upper bits as garbage; and this matters
> because we are subsequently using all 64 bits of the register in a later
> operation. We could also use a signed long, even long long, or written
> it as: (store ? 6ULL : 5ULL) instead of using a temporary variable. The
> crux of the fix is that you have to tell asm() that you want a 64-bit
> value written (the unpatched (store ? 6 : 5) is only a 32-bit value),
> and not whether that value is signed or unsigned (since the
> representation of both 6 and 5 are the same regardless of whether the
> type being written into the register is signed or not).
Thank you so much for the detailed explanation :).
I did not think about the instruction that will be used by the compiler
to handle the values. Definitely learned something new!
prev parent reply other threads:[~2018-05-03 16:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-02 12:52 [Qemu-devel] [PATCH] s390-ccw: force diag 308 subcode to unsigned long Cornelia Huck
2018-05-02 12:56 ` Christian Borntraeger
2018-05-02 13:32 ` Thomas Huth
2018-05-03 15:20 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-05-03 15:25 ` [Qemu-devel] " Farhan Ali
2018-05-03 15:44 ` Cornelia Huck
2018-05-03 16:05 ` Farhan Ali
2018-05-03 15:48 ` Eric Blake
2018-05-03 16:03 ` Farhan Ali [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.