Re: [Xen-devel] Question about apic ipi interface

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 09.05.2013 10:56, Ian Campbell wrote:
> On Wed, 2013-05-08 at 17:26 +0100, Stefan Bader wrote:
>> On 23.04.2013 12:07, Stefan Bader wrote:
>>> I was looking at some older patch and there is one thing I do not 
>>> understand.
>>>
>>> commit f447d56d36af18c5104ff29dcb1327c0c0ac3634
>>>     xen: implement apic ipi interface
>>>
>>> Specifically there the implementation of xen_send_IPI_mask_allbutself().
>>>
>>> void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
>>>                                 int vector)
>>> {
>>>         unsigned cpu;
>>>         unsigned int this_cpu = smp_processor_id();
>>>
>>>         if (!(num_online_cpus() > 1))
>>>                 return;
>>>
>>>         for_each_cpu_and(cpu, mask, cpu_online_mask) {
>>>                 if (this_cpu == cpu)
>>>                         continue;
>>>
>>>                 xen_smp_send_call_function_single_ipi(cpu);
>>>         }
>>> }
>>>
>>> Why is this using xen_smp_send_call_function_single_ipi()? This dumps the
>>> supplied vector and always uses XEN_CALL_FUNCTION_SINGLE_VECTOR. In 
>>> contrast the
>>> xen_send_IPI_all() and xen_send_IPI_self() keep the (mapped) vector.
>>>
>>> Mildly wondering about whether call function would need special casing (just
>>> because xen_smp_send_call_function_ipi() is special). But I don't have the 
>>> big
>>> picture there.
>>>
>>
>> This never got really answered, so lets try this: Does the following patch 
>> seem
>> to make sense?
> 
> It certainly seems too. Although I traced the call chain back to
> default_send_IPI_allbutself() which nothing actually seems to call. Or
> my grep is faulty...
> 
> There is a call path via send_IPI_allbutself which looks to only
> potentially be called as:
>         apic->send_IPI_allbutself(APIC_DM_NMI);
>         apic->send_IPI_allbutself(NMI_VECTOR);
> (the other calls are in native_smp_foo which I assume doesn't apply).

If I am not missing something send_IPI_allbutself as a function only exists on
non-x86 archs. And as you say the other users seem to be in a function that gets
replaced under Xen PV.

> 
> xen_map_vector( doesn't seem to handle those two, I'm not sure if that
> will constitute a regression since it doesn't seem likely that either of
> those would have worked properly with the current code either.

Yeah best case it would hide unimplemented vectors to be used. With the change
this would at least be obvious. Like I found when realizing that all this only
applies to dom0 because other PV domUs seem to get the noop_apic assigned. So
one can do a "echo l >/proc/sysrq-trigger" and get vector 0x2 (NMI_VECTOR) not
implemented (in dom0). Luckily the only bad thing happening is a delay and no
stack traces being produced.

-Stefan

> 
> Ian.
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel