Re: [PATCH v3 7/7] xen/arm: introduce new xen,enhanced property value

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi,

> On 6 Sep 2022, at 08:54, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On 06/09/2022 08:24, Bertrand Marquis wrote:
>>> I agree with Julien: I prefer this proposal compared to the earlier one
>>> by Bertrand and Rahul because I think it is a lot clearer and "ENHANCED"
>>> should mean everything. Also, it makes it easier from a compatibility
>>> perspective because it matches the current definition.
>>> 
>>> But I also agree with Bertrand that "BASIC" doesn't sound nice. I think
>>> we should keep "DOM0LESS_ENHANCED" and "DOM0LESS_XENSTORE" as suggested
>>> here, but replace "DOM0LESS_ENHANCED_BASIC" with something better. Some
>>> ideas:
>>> 
>>> - DOM0LESS_ENHANCED_LIMITED
>>> - DOM0LESS_ENHANCED_MINI
>> Personally I do not find those more clear then BASIC
>>> - DOM0LESS_ENHANCED_NO_XS
>> This has the problem to be true now but would need renaming if we introduce 
>> a definition for an other bit.
> 
> Internal renaming is not a problem.

Then let’s go for this.

Cheers
Bertrand

> 
>>> - DOM0LESS_ENHANCED_GNT_EVTCHN
>> I would vote for this one as it explicitly state what is in so the bitset 
>> system is even more meaningful.
> 
> This would be fine if the flag were doing what it is supposed to do (i.e 
> enable grant-table and event-channel only). However, so far, it will expose 
> any Xen features but Xenstore. So of the features are strictly not necessary 
> for the grant-table/event-channel support (e.g. ballooning facilities, 
> runstate...).
> 
> The name would also really confusing in the definition of ENHANCED (XENSTORE 
> | GNT_EVTCHN). Does this mean the domain cannot use the runstate?
> 
> Cheers,
> 
> -- 
> Julien Grall
>