Shan, Haitao
2008-Apr-10 09:45 UTC
[Xen-devel] [PATCH][RFC] Change edge-interrupt handling in Xen
Hi, Keir, These two patch will demonstrate our thoughts of how edge-interrupt can be handled in Xen. Following the dicussion with MSI in recent mail threads, edge-interrupt can be handled like this: 1> ACK (write EOI) for the first interrupt. 2> If the second comes and the first is still in service, mask the interrupt. 3> unmask the interupt when all work is done. While this is clear in native linux kernel, it is not so in Xen. Because Xen does not require the guest use EOI hypercall for edge interrupt and hence does not know when guest has finished handling to edge interrupt, we have problems in how to judge 2> and 3>. We solve the problem in this way: Move pirq_needs_eoi from dom0''s owe memory to share page. Xen will chage the bit in pirq_needs_eoi dynamically. Xen uses pending status to judge whether the first one is handled. On receiving EOI hypercall from guest, unmask the interrupt. Do you think this approach is viable? The two patches are for xen and kernel respectively. <<handle_edge_irq_kernel.patch>> <<handle_edge_ird.patch>> Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Apr-10 10:22 UTC
[Xen-devel] Re: [PATCH][RFC] Change edge-interrupt handling in Xen
On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@intel.com> wrote:> We solve the problem in this way: > Move pirq_needs_eoi from dom0''s owe memory to share page. > Xen will chage the bit in pirq_needs_eoi dynamically. > Xen uses pending status to judge whether the first one is handled. > On receiving EOI hypercall from guest, unmask the interrupt. > > Do you think this approach is viable?It breaks the existing guest interface and I think it¹s probably unnecessary. Unmask the interrupt on a one-millisecond timer. That suitably limits interrupt storms and should guarantee the system makes progress. If we are taking this path very often then we have a very odd system. Perhaps log something via printk() if we take the path frequently (for some arbitrary definition of frequently¹)? Remember that right now we have no storm handling for edge-triggered interrupts and we have no problems so far. The only problem we¹ve ever seen is with MSI and an e1000 NIC, at start of day only, and even that can¹t be repro¹ed reliably. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Haitao Shan
2008-Apr-10 11:58 UTC
Re: [Xen-devel] Re: [PATCH][RFC] Change edge-interrupt handling in Xen
Thanks! I will follow the timer approach. Best Regards Shan Haitao 2008/4/10, Keir Fraser <keir.fraser@eu.citrix.com>:> > On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@intel.com> wrote: > > We solve the problem in this way: > Move pirq_needs_eoi from dom0''s owe memory to share page. > Xen will chage the bit in pirq_needs_eoi dynamically. > Xen uses pending status to judge whether the first one is handled. > On receiving EOI hypercall from guest, unmask the interrupt. > > Do you think this approach is viable? > > > It breaks the existing guest interface and I think it''s probably > unnecessary. Unmask the interrupt on a one-millisecond timer. That suitably > limits interrupt storms and should guarantee the system makes progress. If > we are taking this path very often then we have a very odd system. Perhaps > log something via printk() if we take the path frequently (for some > arbitrary definition of ''frequently'')? > > Remember that right now we have *no* storm handling for edge-triggered > interrupts and we have no problems so far. The only problem we''ve ever seen > is with MSI and an e1000 NIC, at start of day only, and even that can''t be > repro''ed reliably. > > -- Keir > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel