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-f5d65c385...@suse.com
--
Julien Grall
