>>> On 24.05.18 at 16:14, <si...@invisiblethingslab.com> wrote:
> Jan Beulich:
>>>>> 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).
>
> 4 cores + HT, so 8 CPUs from Xen's PoV.
May I ask you to do two things:
1) confirm that you can offline CPUs successfully using xen-hptool,
2) add a printk() to the code above making clear whether/when any
of the mappings actually get zapped?
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
