Hi Jan,
On 20/12/2022 08:45, Jan Beulich wrote:
On 20.12.2022 09:40, Julien Grall wrote:
On 19/12/2022 12:48, Jan Beulich wrote:
On 16.12.2022 13:26, Julien Grall wrote:
On 19/10/2022 08:41, Jan Beulich wrote:
RFC: HVM guests (on x86) can change bitness and hence layout (and size!
and alignment) of the runstate area. I don't think it is an option
to require 32-bit code to pass a range such that even the 64-bit
layout wouldn't cross a page boundary (and be suitably aligned). I
also don't see any other good solution, so for now a crude approach
with an extra boolean is used (using has_32bit_shinfo() isn't race
free and could hence lead to overrunning the mapped space).
I think the extra check for 32-bit code to pass the check for 64-bit
layout would be better.
I'm afraid I can't derive from your reply what it is you actually want.
I think for 32-bit call, we also want to check the address provide will
also pass the 64-bit check (i.e. if used as a 64-bit layout, the area
would not cross a page boundary and be suitably aligned).
But that's specifically what I say I don't think is an option. First and
foremost because of the implication on 32-bit callers: They're need to
use magic to get hold of the size of the 64-bit variant of the struct.
I understand that. But I am not aware of any other (simple) approach
where you could have race free code.
So between a non-race free code and exposing the restriction to the
guest, I would chose the latter.
Cheers,
--
Julien Grall
