Re: MISRA violations in hypercall-defs

[Julien Grall <julien@xxxxxxx>]

Hi,

On 09/08/2023 23:06, Stefano Stabellini wrote:
> On Wed, 9 Aug 2023, Julien Grall wrote:
> > Hi,
> >
> > On 09/08/2023 21:35, Stefano Stabellini wrote:
> > > P.S.
> > > Julien, Bertrand, do you think we should unsupport (in SUPPORT.md, today
> > > it is not clarified) 32-bit guests on a 64-bit ARM hypervisor?
> > I read your explanation above and I don't really understand why you would want
> > to de-support it. This works pretty well and I am not aware of any issue right
> > now to run 32-bit guest on 64-bit HW.
> I am happy either way. The reason why I brought it up is that we don't
> have a specific test for this in gitlab-ci
But a gitlab CI test can be added, right? I mean it would seem to be odd 
to use this as a justification because a lot of features (e.g. 
passthrough, suspend/resume...) would end up to be de-support it as 
gitlab CI is still in early stage.
> and Jan raised concerns that
> greater-than 32-bit values as possible as ret from hypercalls on a
> 64-bit build of Xen.
This is a known problem and it was discussed several times on the ML in 
the past years.
There is a theorical problem because in theory all the hypercalls could 
return a value that can't fit in 32-bit.
However, AFAIK, only the memory hypercall XENMEM_maximum_gpfn may return 
a 64-bit value on 64-bit Xen.
It is not a problem for a 32-bit domain issues the hypercall on itself 
because the guest physical maximum address should never be greater than 
40-bit (so 28-bit page frame number) and therefore could fit in 32-bit.
The only problem is if you want to use a 32-bit toolstack on 64-bit. But 
Jan sent a patch for SUPPORT.md to clarify this is not meant to always 
work (see [1]).
Please let me know if you are aware of any other truncations.

Cheers,

[1] 6d6144f6-489e-d9b0-b590-f5d65c385116@xxxxxxxx


--
Julien Grall