[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 04/10] domain: update GADDR based runstate guest area
On 20/12/2022 09:59, Jan Beulich wrote:
On 20.12.2022 09:48, Julien Grall wrote:
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.
My reference to using has_32bit_shinfo() not being race free was to avoid
suggestions in that direction. There's no use of this function in the
patch here, nor in the one where the new boolean field is actually written
to. The solution as presented is, afaict, both simple and race free. It
merely isn't very nice.
Ah! I misunderstood what you original wrote. Thanks for the clarification.
Cheers,
--
Julien Grall
|
