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

[Julien Grall <julien@xxxxxxx>]

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.

> > - 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