RE: [Xen-merge] General xen question on send_IPI_self

["Martin J. Bligh" <mbligh@xxxxxxxxxx>]

--Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> wrote (on Sunday, August 07, 2005 
23:38:14 +0100):

>  
>> This looks dangerous to me, instintively, though I don't know 
>> what you're doing in this space, or why. How can you get away 
>> with a no-op for send_IPI_self?
>> 
>> # ifndef CONFIG_SMP
>> void fastcall send_IPI_self(int vector)
>> {
>> # ifndef CONFIG_XEN
>>         unsigned int cfg;
>> 
>>         /*
>>          * Wait for idle.
>>          */
>>         apic_wait_icr_idle();
>>         cfg = APIC_DM_FIXED | APIC_DEST_SELF | vector | 
>> APIC_DEST_LOGICAL;
>>         /*
>>          * Send the IPI. The write to APIC_ICR fires this off.
>>          */
>>         apic_write_around(APIC_ICR, cfg); #endif } #endif /* 
>> !CONFIG_SMP */
> 
> send_IPI_self is used only by hw_resend_irq(), which is not required for
> our virtualised interrupts. send_IPI_self() was virtualised properly in
> smp.c, but I guess someone didn't bother for io_apic.c, since it's not
> used anyway.

Hmmm. I'd feel much more comfortable shortcuting the *usage* inside
hw_resend_irq(), in that case? Someone might decide to use send_IPI_self
for something you do need? If we don't have an easy way of making an
defn I'll comment it out, so it breaks at compile time ... having the
null op one seems like asking for future trouble?

OK, it's not super-likely to get used by other things, since it's an odd
thing to do, but still seems like a good principle.

M.


_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge