Re: [PATCH RFC 04/10] domain: update GADDR based runstate guest area

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

> So between a non-race free code and exposing the restriction to the 
> guest, I would chose the latter.
> 
> Cheers,
>