xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: sstabellini@kernel.org, keir@xen.org, andre.przywara@arm.com,
	ian.jackson@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [for-4.7 1/2] xen/bitops: Introduce macros to generate mask
Date: Wed, 20 Apr 2016 13:35:17 +0100	[thread overview]
Message-ID: <57177785.20909@arm.com> (raw)
In-Reply-To: <570FC3E402000078000E6797@prv-mh.provo.novell.com>

Hi Jan,

On 14/04/16 16:23, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@arm.com> 04/14/16 5:08 PM >>>
>> On 14/04/16 15:56, Jan Beulich wrote:
>>>>>> Julien Grall <julien.grall@arm.com> 04/14/16 10:55 AM >>>
>>>> On 14/04/2016 05:01, Jan Beulich wrote:
>>>>>>>> Julien Grall <julien.grall@arm.com> 04/13/16 6:01 PM >>>
>>>>>> --- a/xen/include/xen/bitops.h
>>>>>> +++ b/xen/include/xen/bitops.h
>>>>>> @@ -3,6 +3,17 @@
>>>>>     >#include <asm/types.h>
>>>>>     >
>>>>>     >/*
>>>>>> + * Create a contiguous bitmask starting at bit position @l and ending at
>>>>>> + * position @h. For example
>>>>>> + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x000000ffffe00000.
>>>>>> + */
>>>>>> +#define GENMASK(h, l) \
>>>>>> +    (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
>>>>>> +
>>>>>> +#define GENMASK_ULL(h, l) \
>>>>>> +    (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h))))
>>>>>
>>>>> Irrespective of Linux perhaps considering them useful, I'm not sure they
>>>>> are (and ISTR these macros having got proposed before).
>>>>
>>>> This is useful on ARM to generate mask for register. For instance, the
>>>> following patch introduces mask for the register HPFAR_EL2. Only the
>>>> bits [4:39] are usable, the rest are RES0.
>>>>
>>>> For ARM, RES0 means the bit is currently read as zero but the software
>>>> should not rely on it to preserve forward compatibility. So we want to
>>>> mask those bits to avoid breakage with new version of the architecture.
>>>
>>>    All understood and needed on every kind of architecture. Yet what's wrong
>>> with expressing this is as 0xfffffffff0, as is being done most everywhere else?
>>
>> It is less intuitive to read and it is easier to make a mistake in the mask.
>
> Well, I guess that depends on the person reading/writing the respective piece
> of code. To me the macroized form would at least require getting used to.

It is a matter of taste. Is there any reason to not allow different way 
to create a mask?

In the case of ARM, the macro version helps to find quickly if a mask 
matches the ARM specification. It is also less error-prone with 64-bit mask.

If you are concerned to have this macro in the common, I would be fine 
to carry it in asm-arm/.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-04-20 12:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 15:55 [for-4.7 0/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2 Julien Grall
2016-04-13 15:55 ` [for-4.7 1/2] xen/bitops: Introduce macros to generate mask Julien Grall
2016-04-13 18:07   ` Stefano Stabellini
2016-04-13 18:14   ` Andrew Cooper
2016-04-14  8:47     ` Julien Grall
2016-04-14  4:01   ` Jan Beulich
2016-04-14  8:55     ` Julien Grall
2016-04-14 14:56       ` Jan Beulich
2016-04-14 15:08         ` Julien Grall
2016-04-14 15:23           ` Jan Beulich
2016-04-20 12:35             ` Julien Grall [this message]
2016-04-20 16:43               ` Jan Beulich
2016-04-22 11:33                 ` Julien Grall
2016-04-22 11:49                   ` Stefano Stabellini
2016-04-22 15:33                     ` Julien Grall
2016-04-22 15:42                       ` Stefano Stabellini
2016-04-13 15:55 ` [for-4.7 2/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2 Julien Grall
2016-04-13 18:17   ` Stefano Stabellini
2016-04-13 19:11   ` Tamas K Lengyel
2016-04-13 20:33   ` André Przywara
2016-04-14 17:47 ` [for-4.7 0/2] " Wei Liu

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=57177785.20909@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).