[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH 1/5] x86/PV: consistently inline {,un}adjust_guest_l<N>e()
Commit 8a74707a7c ("x86/nospec: Use always_inline to fix code gen for evaluate_nospec") converted inline to always_inline for adjust_guest_l[134]e(), but left adjust_guest_l2e() and unadjust_guest_l3e() alone without saying why these two would differ in the needed / wanted treatment. Adjust these two as well. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> --- Actually I question the need for always_inline here, for two reasons: 1) All that's guarded are updates to local variables, depending on merely the values held by these local variables (really: function arguments) on input. As a result it would look to me as if we wanted evaluate_nospec()-free variants of is_pv{,_32bit}_domain() and alike, to be used e.g. here. 2) These functions don't act as predicates, and hence the concern expressed in said commit doesn't apply here: Callers wouldn't observe misplaced LFENCEs, as they don't use the results of these helpers for further (direct) code flow control. --- So far I've observed only clang to not inline the two functions when just "inline" is in place. --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -99,8 +99,8 @@ static always_inline l1_pgentry_t adjust return l1e; } -static inline l2_pgentry_t adjust_guest_l2e(l2_pgentry_t l2e, - const struct domain *d) +static always_inline l2_pgentry_t adjust_guest_l2e(l2_pgentry_t l2e, + const struct domain *d) { if ( likely(l2e_get_flags(l2e) & _PAGE_PRESENT) && likely(!is_pv_32bit_domain(d)) ) @@ -119,8 +119,8 @@ static always_inline l3_pgentry_t adjust return l3e; } -static inline l3_pgentry_t unadjust_guest_l3e(l3_pgentry_t l3e, - const struct domain *d) +static always_inline l3_pgentry_t unadjust_guest_l3e(l3_pgentry_t l3e, + const struct domain *d) { if ( unlikely(is_pv_32bit_domain(d)) && likely(l3e_get_flags(l3e) & _PAGE_PRESENT) )
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |