[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/3] xen/arm, tools: Add a new HVM_PARAM_MAGIC_BASE_PFN key in HVMOP
Hi Jan, On 4/26/2024 2:50 PM, Jan Beulich wrote: On 26.04.2024 08:30, Henry Wang wrote:On 4/26/2024 2:21 PM, 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 5Considering 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.Thanks for the feedback. These make sense. I think probably dom0less/hyperlaunch will have similar use cases so the number 3 can be reused at that time. Therefore, in v2, I will add more description in commit message, a comment on top of this macro and protect it with #ifdef. Hope this will address your concern. Thanks.FTAOD: If you foresee re-use by hyperlaunch, re-using a previously used number may need re-considering. Which isn't to say that number re-use is excluded here, but it would need at least figuring out (and then stating) what exactly the number was used for and until when. I just did a bit search and noticed that the number 3 was used to be #define HVM_PARAM_APIC_ENABLED 3and it was removed 18 years ago in commit: 6bc01e4efd50e1986a9391f75980d45691f42b74 So I think we are likely to be ok if reuse 3 on Arm with proper #ifdef. Kind regards, Henry Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |