[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-4.19 v4 1/8] xen/include: add macro ISOLATE_LOW_BIT


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 16 Nov 2023 11:25:20 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=11NTYYc8ynzNr+TD5Q+eSd5YiRCqhuwxGSHS/BM615w=; b=WIGtwsAiws0C4JKXIMATzfk5gPaho/l6ovFyTnb/BTqi+S9KS1/uSjZFIoHUiV7xd6/vUAMRj+8dtSuMZsFK7L9k1UEEchXD9uqX3FLypx/ibI/3C5r/Z9eW5B+ArZwsoMrXF6zMixOl/aynb6SDPWK16ZNAm6ynUG6J0bZOjUdFk4Vk3OgsPyOTvUD4bHmdFR+3cu8nTOV9OaaJOZgCrh8b4dZeeLE+6ZAmpzl52ZZXHP7IBAbaXpHPXzxI21mkIZJVgaMd3uw++sG2nWhiOwjBcRNXXxoF5LG62RmRbo3WNkKVKA/so0mJTv7S1huMI1WwSeXO5CEDfKamNs6+Ag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AIgN3eDVapxb9eVBLjdflWeLCqHfqNoeeFCpdFcAR7eG4rAro+hJxDqcwHmSmF3/pNV6PqyB4IaGnM6A5KOLTDqvWygHkocaf90CCSZdQrRoRDGRTqL25znpAmf7lUtr4KGk5NAXKzbW2yPNNCApLbZ3j/HmcovV/aLKxB6/Smr9f0BNAXBPrhQv20BscAJ8QyysrKGJClPDiu57vOjtUZ4iAffec1ZtLc7HgxXMtW3DnBtxkdrCyBIcB+RQmEJVffW/bOk8h85rc89AgSmAW5E22rsuJVIUcwsPYDXcapzQS8OYe4p0/y+Azrdu07LKMRm4k50koUuJhbT3kfV8Tw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 16 Nov 2023 10:26:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.11.2023 11:02, Nicola Vetrini wrote:
> On 2023-11-16 09:26, Jan Beulich wrote:
>> On 31.10.2023 11:20, Jan Beulich wrote:
>>> On 31.10.2023 11:03, Nicola Vetrini wrote:
>>>> On 2023-10-31 09:28, Nicola Vetrini wrote:
>>>>> On 2023-10-31 08:43, Jan Beulich wrote:
>>>>>> On 30.10.2023 23:44, Stefano Stabellini wrote:
>>>>>>> On Mon, 30 Oct 2023, Jan Beulich wrote:
>>>>>>>> On 27.10.2023 15:34, Nicola Vetrini wrote:
>>>>>>>>> --- a/xen/include/xen/macros.h
>>>>>>>>> +++ b/xen/include/xen/macros.h
>>>>>>>>> @@ -8,8 +8,14 @@
>>>>>>>>>  #define DIV_ROUND(n, d) (((n) + (d) / 2) / (d))
>>>>>>>>>  #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
>>>>>>>>>
>>>>>>>>> -#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
>>>>>>>>> -#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
>>>>>>>>> +/*
>>>>>>>>> + * Given an unsigned integer argument, expands to a mask where
>>>>>>>>> just the least
>>>>>>>>> + * significant nonzero bit of the argument is set, or 0 if no 
>>>>>>>>> bits
>>>>>>>>> are set.
>>>>>>>>> + */
>>>>>>>>> +#define ISOLATE_LOW_BIT(x) ((x) & -(x))
>>>>>>>>
>>>>>>>> Not even considering future Misra changes (which aiui may require
>>>>>>>> that
>>>>>>>> anyway), this generalization of the macro imo demands that its
>>>>>>>> argument
>>>>>>>> now be evaluated only once.
>>>>>>>
>>>>>>> Fur sure that would be an improvement, but I don't see a trivial 
>>>>>>> way
>>>>>>> to
>>>>>>> do it and this issue is also present today before the patch.
>>>>>>
>>>>>> This was an issue here for MASK_EXTR() and MASK_INSR(), yes, but 
>>>>>> the
>>>>>> new
>>>>>> macro has wider use, and there was no issue elsewhere so far.
>>>>>>
>>>>>>> I think it
>>>>>>> would be better to avoid scope-creeping this patch as we are 
>>>>>>> already
>>>>>>> at
>>>>>>> v4 for something that was expected to be a trivial mechanical 
>>>>>>> change.
>>>>>>> I
>>>>>>> would rather review the fix as a separate patch, maybe sent by you 
>>>>>>> as
>>>>>>> you probably have a specific implementation in mind?
>>>>>>
>>>>>> #define ISOLATE_LOW_BIT(x) ({ \
>>>>>>     typeof(x) x_ = (x); \
>>>>>>     x_ & -x_; \
>>>>>> })
>>>>>>
>>>>>> Hard to see the scope creep here. What I would consider scope creep 
>>>>>> I
>>>>>> specifically didn't even ask for: I'd like this macro to be
>>>>>> overridable
>>>>>> by an arch. Specifically (see my earlier naming hint) I'd like to 
>>>>>> use
>>>>>> x86's BMI insn BLSI in the context of "x86: allow Kconfig control 
>>>>>> over
>>>>>> psABI level", when ABI v2 or higher is in use.
>>>>>
>>>>> I appreciate you suggesting an implementation; I'll send a v5
>>>>> incorporating it.
>>>>
>>>> There's an issue with this approach, though: since the macro is used
>>>> indirectly
>>>> in expressions that are e.g. case labels or array sizes, the build 
>>>> fails
>>>> (see [1] for instance).
>>>> Perhaps it's best to leave it as is?
>>>
>>> Hmm. I'm afraid it's not an option to "leave as is", not the least 
>>> because
>>> - as said - I'm under the impression that another Misra rule requires
>>> macro arguments to be evaluated exactly once. Best I can think of 
>>> right
>>> away is to have a macro for limited use (to address such build issues)
>>> plus an inline function (for general use). But yes, maybe that then 
>>> indeed
>>> needs to be a 2nd step.
>>
>> While I've committed this patch (hoping that I got the necessary 
>> context
>> adjustment right for the 
>> automation/eclair_analysis/ECLAIR/deviations.ecl
>> change), I'd like to come back to this before going further with users 
>> of
>> the new macro: I still think we ought to try to get to the single
>> evaluation wherever possible. The macro would then be used only in 
>> cases
>> where the alternative construct (perhaps an isolate_lsb() macro, living
>> perhaps in xen/bitops.h) cannot be used. ISOLATE_LSB() would then want 
>> to
>> gain a comment directing people to the "better" sibling. Thoughts?
> 
> Having the users in place would help me estimate the remaining work that 
> needs to be done on this rule and see if my local counts match up with 
> the counts in staging.

By "having the users in place", you mean you want other patches in this
and the dependent series to be committed as-is (except for the name
change)? That's what I'd like to avoid, as it would mean touching all
those use sites again where the proposed isolate_lsb() could be used
instead. I'd rather see all use sites be put into their final shape
right away.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.