Re: [PATCH 2/2] xen/multicall: Change nr_calls to uniformly be unsigned long

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.11.2024 04:15, Stefano Stabellini wrote:
> It is challenging to create a solution that satisfies everyone for this
> patch. However, we should add R8.3 to the clean list as soon as possible
> to enable rule blocking in GitLab-CI. Failing to do so risks introducing
> regressions, as recently occurred, undoing the significant efforts made
> by Bugseng and the community over the past year.
> 
> Unless there is a specific counterproposal, let us proceed with
> committing this patch.

Well, I find this odd. We leave things sit in limbo for months and then
want to go ahead with a controversial solution? Rather than actually
(and finally) sorting out the underlying disagreement (of which there
are actually two sufficiently separate parts)? Plus ...

> On Mon, 24 Jun 2024, Jan Beulich wrote:
>> On 21.06.2024 22:58, Andrew Cooper wrote:
>>> Right now, the non-compat declaration and definition of do_multicall()
>>> differing types for the nr_calls parameter.
>>>
>>> This is a MISRA rule 8.3 violation, but it's also time-bomb waiting for the
>>> first 128bit architecture (RISC-V looks as if it might get there first).
>>>
>>> Worse, the type chosen here has a side effect of truncating the guest
>>> parameter, because Xen still doesn't have a clean hypercall ABI definition.
>>>
>>> Switch uniformly to using unsigned long.
>>
>> And re-raising all the same question again: Why not uniformly unsigned int?
>> Or uint32_t?

... this question of mine effectively represents a concrete alternative
proposal (or even two, if you like).

The two parts where there appears to be disagreement are:
1) When to (not) use fixed width types, as presently outlined in
   ./CODING_STYLE.
2) How to type C function parameters called solely from assembly code (of
   which the hypercall handlers are a subset).

And maybe
2b) How to best express such function parameters when they're (sometimes)
    shared between native and compat handlers.

Of course 2) is affected by, as Andrew validly says, there not being a
formally clean ABI definition.

My fear is that if this gets committed as is, it'll be used as a handle to
force in further similarly questionable / controversial changes to other
hypercall handlers. Which is why I think the controversy needs sorting out
first (which admittedly is hard when the ABI is fuzzy).

Jan