Hi Julien, > On 2 Sep 2022, at 4:05 pm, Julien Grall <jul...@xen.org> wrote: > > Hi Bertrand, > > On 02/09/2022 15:51, Bertrand Marquis wrote: >>> On 1 Sep 2022, at 19:15, Julien Grall <jul...@xen.org> wrote: >>> AFAIU, it is not possible to have *_xenstore = true and *_enhanced = false. >>> I think it would be clearer if ``dom0less_enhanced`` is turned to an enum >>> with 3 values: >>> - None >>> - NOXENSTORE/BASIC >>> - FULLY_ENHANCED >>> >>> If we want to be future proof, I would use a field 'flags' where non-zero >>> means enhanced. Each bit would indicate which features of Xen is exposed. >> I think that could be a good solution if we do it this way: >> - define a dom0less feature field and have defines like the following: >> #define DOM0LESS_GNTTAB >> #define DOM0LESS_EVENTCHN >> #define DOM0LESS_XENSTORE > >> - define dom0less enhanced as the right combination: >> #define DOM0LESS_ENHANCED = (DOM0LESS_GNTTAB| DOM0LESS_EVENTCHN| >> DOM0LESS_XENSTORE) > > I would rather introduce DOM0LESS_ENHANCED_BASIC (or similar) instead of > defining a bit for gnttab and evtchn. This will avoid the question of why we > are introducing bits for both features but not the hypercall... > > As this is an internal interface, it would be easier to modify afterwards.
How about this? /* * List of possible features for dom0less domUs * * DOM0LESS_ENHANCED_BASIC: Xen PV interfaces, including grant-table and * evtchn, will be enabled for the VM. * DOM0LESS_XENSTORE: Xenstore will be enabled for the VM. * DOM0LESS_ENHANCED: Xen PV interfaces, including grant-table xenstore * and evtchn, will be enabled for the VM. */ #define DOM0LESS_ENHANCED_BASIC BIT(0, UL) #define DOM0LESS_XENSTORE BIT(1, UL) #define DOM0LESS_ENHANCED (DOM0LESS_ENHANCED_BASIC | DOM0LESS_XENSTORE) Regards, Rahul