Hi all,

> On Oct 20, 2023, at 07:48, Andrew Cooper <andrew.coop...@citrix.com> wrote:
> 
> On 18/10/2023 9:02 am, Tamas K Lengyel wrote:
>> When mapping in the shared_info page to a fork the m2p entry wasn't set
>> resulting in the shared_info being reset even when the fork reset was called
>> with only reset_state and not reset_memory. This results in an extra
>> unnecessary TLB flush.
>> 
>> Fixes: 1a0000ac775 ("mem_sharing: map shared_info page to same gfn during 
>> fork")
>> Signed-off-by: Tamas K Lengyel <ta...@tklengyel.com>
>> ---
>> xen/arch/x86/mm/mem_sharing.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
>> index 94b6b782ef..142258f16a 100644
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1847,6 +1847,8 @@ static int copy_special_pages(struct domain *cd, 
>> struct domain *d)
>>                                 p2m_ram_rw, p2m->default_access, -1);
>>             if ( rc )
>>                 return rc;
>> +
>> +            set_gpfn_from_mfn(mfn_x(new_mfn), gfn_x(old_gfn));
>>         }
>>     }
>> 
> 
> Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
> 
> CC Henry.  This needs a view about a release ack.
> 
> Cons: it's been broken since Xen 4.14 and we're very deep into the 4.18
> code freeze.
> 
> Pros: it's a bug and would clearly qualify for backport, and is in a
> niche feature so isn't plausibly going to adversely affect other users.

Given the fact that it will be backported anyway, I had the same discussion 
with Juergen
in his thread [1]. So if we can bear the risk of delaying merging this patch 
for a week,
would it be ok to wait for the release and backport this patch to the stable 
tree? Thanks!

[1] 
https://lore.kernel.org/xen-devel/83e6dcf6-926c-43a6-94d2-eb3b2c444...@arm.com/

Kind regards,
Henry

> 
> ~Andrew


Reply via email to