>>> On 24.05.18 at 16:00, <si...@invisiblethingslab.com> wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it may only be unmapped when no other online
>> CPU uses that same page.
>>
>> Reported-by: Simon Gaiser <si...@invisiblethingslab.com>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -876,7 +876,21 @@ static void cleanup_cpu_root_pgt(unsigne
>>
>> free_xen_pagetable(rpt);
>>
>> - /* Also zap the stub mapping for this CPU. */
>> + /*
>> + * Also zap the stub mapping for this CPU, if no other online one uses
>> + * the same page.
>> + */
>> + if ( stub_linear )
>> + {
>> + unsigned int other;
>> +
>> + for_each_online_cpu(other)
>> + if ( !((per_cpu(stubs.addr, other) ^ stub_linear) >>
>> PAGE_SHIFT) )
>> + {
>> + stub_linear = 0;
>> + break;
>> + }
>> + }
>> if ( stub_linear )
>> {
>> l3_pgentry_t *l3t = l4e_to_l3e(common_pgt);
>
> Tried this on-top of staging (fc5805daef) and I still get the same
> double fault.
Hmm, it worked for me offlining (and later re-onlining) several pCPU-s. What
size a system are you testing on? Mine has got only 12 CPUs, i.e. all stubs
are in the same page (and I'd never unmap anything here at all).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
