> From: Tian, Kevin
> Sent: Tuesday, May 10, 2011 11:24 AM
>
> > From: Thomas Gleixner [mailto:tglx@xxxxxxxxxxxxx]
> > Sent: Monday, May 09, 2011 8:37 PM
> >
> > On Mon, 9 May 2011, Stefano Stabellini wrote:
> >
> > > On Mon, 9 May 2011, Tian, Kevin wrote:
> > > > yes, with your patch this issue disappears, since you explicitly
> > > > make mask/unmask as a nop for xen_percpu_chip, which effectively
> > > > avoids them from undesired unmask when doing the migration. Though
> > > > it works, it's not intuitive as to me it's an workaround to make
> > > > Xen chip
> > implementation adapting to specific fixup_irqs logic.
> > >
> > > I have been tring to follow the example of existing supported drivers.
> > > The only x86 driver I could find that uses handle_percpu_irq is
> > > uv_irq that does exatly the same thing.
> >
> > Which is a good enough argument to make that change at the common code
> > level instead of having fancy workarounds here and there.
> >
>
> So Thomas, what's your suggestion to continue here? Is my original patch to
> skip percpu irq in common code a good option to go, or you want a cleaner code
> in other form? Once it's clear I'll discuss with Stefano e.g. possibly merge
> with
> his cleanup patch series. :-)
>
Hi, Thomas,
any response on this? Sorry that you may explain your comments clearly in
earlier
thread, but I may not catch all of them in one place.
I sent out two fixes here:
[1/2] don't move irq when it's percpu type
[2/2] don't unmask irq when it's disabled at irqchip level
for [2/2], as you explained it's legitimate to mask/unmask a disabled irq since
from
irqchip level mask/disable actually means same thing. The only possible gain to
do that is to avoid a potential extra interrupt, which is a different purpose
as what
I originally target. So for [2/2] I think it's not required now.
for [1/2] I think it's still necessary as it's meaningless to migrate a percpu
type irq.
However Stefano has sent out a cleanup patch for Xen percpu irqchip which uses
nop mask/unmask hack borrowed from uv machine to work around the issue. As
you suggested it's better to consolidate into the common place instead of
scattering
in different places. My view on this common logic is what [1/2] tries to
address, is
it correct? If yes, would you consider taking this patch? Stefano told me that
his
patches will go in in next merge window. So I think either you can take [1/2]
now and
then I'll do cleanup after Stefano's patch is in, or I can rebase my [1/2]
after Stefano's
patch to clean both xen and uv parts.
Let me know your thought.
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home