[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |