Hi Julien,
> On 2 Sep 2022, at 4:05 pm, Julien Grall <[email protected]> wrote:
>
> Hi Bertrand,
>
> On 02/09/2022 15:51, Bertrand Marquis wrote:
>>> On 1 Sep 2022, at 19:15, Julien Grall <[email protected]> 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
