On 20.02.2026 16:06, Andrew Cooper wrote: > On 16/05/2023 8:40 am, Jan Beulich wrote: >> PV domains won't use it, and even HVM ones won't when OOS is turned off >> for them. There's therefore no point in putting extra pressure on the >> (limited) pool of memory. >> >> While there also zap the sh_type_to_size[] entry when OOS is disabled >> altogether. >> >> Signed-off-by: Jan Beulich <[email protected]> >> --- >> v3: New. >> >> --- a/xen/arch/x86/mm/shadow/common.c >> +++ b/xen/arch/x86/mm/shadow/common.c >> @@ -61,7 +61,9 @@ const uint8_t sh_type_to_size[] = { >> [SH_type_l4_64_shadow] = 1, >> [SH_type_p2m_table] = 1, >> [SH_type_monitor_table] = 1, >> +#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC) >> [SH_type_oos_snapshot] = 1, >> +#endif >> }; >> #endif /* CONFIG_HVM */ >> >> @@ -1771,7 +1773,8 @@ static void sh_update_paging_modes(struc >> #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */ >> >> #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC) >> - if ( mfn_eq(v->arch.paging.shadow.oos_snapshot[0], INVALID_MFN) ) >> + if ( !(d->options & XEN_DOMCTL_CDF_oos_off) && >> + mfn_eq(v->arch.paging.shadow.oos_snapshot[0], INVALID_MFN) ) >> { >> int i; > > I've never seen XEN_DOMCTL_CDF_oos_off used. Xapi has no plumbing for > this, and xl only inherited it from xend. > > At this point, OOS is the tested path and OOS_OFF is the untested path. > I think we should remove the flag and let OOS be unconditional like all > the other shadow optimisations.
It being a guest config setting, I'm hesitant. Maybe we should actually make sure it's tested, so that in the case it's needed it could be named as a mitigation for an XSA? Jan
