From: Thomas Gleixner <tglx@linutronix.de>
To: Juergen Gross <jgross@suse.com>
Cc: jeffy.chen@rock-chips.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c
Date: Fri, 7 Jul 2017 19:11:33 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1707071906150.2366@nanos> (raw)
In-Reply-To: <alpine.DEB.2.20.1707071747380.1871@nanos>
On Fri, 7 Jul 2017, Thomas Gleixner wrote:
> On Fri, 7 Jul 2017, Juergen Gross wrote:
>
> > Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
> > unnecessary low level irq function calls") breaks Xen guest
> > save/restore handling.
> >
> > The main problem are the PV devices using Xen event channels as
> > interrupt sources which are represented as an "irq chip" in the kernel.
> > When saving the guest the event channels are masked internally. At
> > restore time event channels are re-established and unmasked via
> > irq_startup().
And how exactly gets irq_startup() invoked on those event channels?
> > I have a patch repairing the issue, but I'm not sure if this way to do
> > it would be accepted. I have exported mask_irq() and I'm doing the
> > masking now through this function. Would the attached patch be
> > acceptable? Or is there a better way to solve the problem?
>
> Without looking at the patch (too lazy to fiddle with attachments right
> now), this is definitely wrong. I'll have a look later tonight.
Not that I'm surprised, but that patch is exactly what I expected. Export a
random function, which helps to paper over the real problem and run away.
These functions are internal for a reason and we worked hard on making
people understand that fiddling with the internals of interrupts is a
NONO. If there are special requirements for a good reason, then we create
proper interfaces and infrastructure, if there is no good reason, then the
problematic code needs to be fixed. There is no exception for XEN.
Can you please explain how that save/restore stuff works and which
functions are involved?
Thanks,
tglx
next prev parent reply other threads:[~2017-07-07 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 14:51 Juergen Gross
2017-07-07 16:41 ` Thomas Gleixner
2017-07-07 17:08 ` Juergen Gross
2017-07-07 17:11 ` Thomas Gleixner [this message]
2017-07-10 7:23 ` Juergen Gross
2017-07-12 15:30 ` Thomas Gleixner
2017-07-12 20:21 ` Thomas Gleixner
2017-07-07 17:09 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1707071906150.2366@nanos \
--to=tglx@linutronix.de \
--cc=boris.ostrovsky@oracle.com \
--cc=jeffy.chen@rock-chips.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=peterz@infradead.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®