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.

~Andrew

Reply via email to