|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 06/12] x86/shadow: restrict OOS allocation to when it's really needed
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 <jbeulich@xxxxxxxx>
>> ---
>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |