On 30.04.2024 04:51, Henry Wang wrote: > On 4/30/2024 8:31 AM, Daniel P. Smith wrote: >> On 4/26/24 02:21, Jan Beulich wrote: >>> On 26.04.2024 05:14, Henry Wang wrote: >>>> --- a/xen/include/public/hvm/params.h >>>> +++ b/xen/include/public/hvm/params.h >>>> @@ -76,6 +76,7 @@ >>>> */ >>>> #define HVM_PARAM_STORE_PFN 1 >>>> #define HVM_PARAM_STORE_EVTCHN 2 >>>> +#define HVM_PARAM_MAGIC_BASE_PFN 3 >>>> #define HVM_PARAM_IOREQ_PFN 5 >>> >>> Considering all adjacent values are used, it is overwhelmingly likely >>> that >>> 3 was once used, too. Such re-use needs to be done carefully. Since you >>> need this for Arm only, that's likely okay, but doesn't go without (a) >>> saying and (b) considering the possible future case of dom0less becoming >>> arch-agnostic, or hyperlaunch wanting to extend the scope. Plus (c) imo >>> this also needs at least a comment, maybe even an #ifdef, seeing how >>> x86- >>> focused most of the rest of this header is. >> >> I would recommend having two new params, > > Sounds good. I can do the suggestion in v2. > >> >> #define HVM_PARAM_HV_RSRV_BASE_PVH 3 >> #define HVM_PARAM_HV_RSRV_SIZE 4 > > I think 4 is currently in use, so I think I will find another couple of > numbers in the end for both of them. Instead of reusing 3 and 4.
Right. There are ample gaps, but any use of values within a gap will need appropriate care. FTAOD using such a gap looks indeed preferable, to avoid further growing the (sparse) array. Alternatively, if we're firm on this never going to be used on x86, some clearly x86-specific indexes (e.g. 36 and 37) could be given non-x86 purpose. Jan
