Re: [PATCH] do_multicall and MISRA Rule 8.3

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Tue, Mar 19, 2024 at 3:39 AM Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
> > The main use of fixed width types, to me, is in interface structure
> > definitions - between Xen and hardware / firmware, or in hypercall
> > structures. I'm afraid I have a hard time seeing good uses outside of
> > that. Even in inline assembly, types of variables used for inputs or
> > outputs don't strictly need to be fixed-width; I can somewhat accept
> > their use there for documentation purposes.
>
>
> Non-ABI interfaces are OK with native types.
>
> Our ABI interfaces are, for better or for worse, described using C
> header files. Looking at these header files, it should be clear the size
> and alignment of all integer parameters.
>
> To that end, I think we should use fixed-width types in all ABIs,
> including hypercall entry points. In my opinion, C hypercall entry
> points are part of the ABI and should match the integer types used in
> the public header files. I don't consider the little assembly code on
> hypercall entry as important.

So as Jan pointed out in the recent call, the "actual" ABI is
"register X, Y, Z are arguments 1-3".  The key thing for me then is
whether it's clear what values in register X are acceptable.  If the C
function implementing the hypercall has an argument of type "unsigned
int", is it clear what values the guest is allowed to be put into the
corresponding register, and how they'll be interpreted, as opposed to
"unsigned long"?

If we can document the expectations, for each architecture, for how
the "native types" map to sizes, then I think that should be
sufficient.

 -George