[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Martin J. Bligh" <mbligh@xxxxxxxxxx>, "xen-merge" <xen-merge@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Sun, 7 Aug 2005 23:38:14 +0100
  • Delivery-date: Sun, 07 Aug 2005 22:36:23 +0000
  • List-id: xen-merge <xen-merge.lists.xensource.com>
  • Thread-index: AcWbl/KrRbRXsERzTbmc94x3z7SougACH5HA
  • Thread-topic: [Xen-merge] General xen question on send_IPI_self

 
> 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.

Ian


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.