From: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Subject: Question: handling early hotplug interrupts
Date: Tue, 29 Aug 2017 17:43:37 -0300 [thread overview]
Message-ID: <e5975dfb-6609-a3b1-7ea7-b9e8fe31b669@linux.vnet.ibm.com> (raw)
Hi,
This is a scenario I've been facing when working in early device
hotplugs in QEMU. When a device is added, a IRQ pulse is fired to warn
the guest of the event, then the kernel fetches it by calling
'check_exception' and handles it. If the hotplug is done too early
(before SLOF, for example), the pulse is ignored and the hotplug event
is left unchecked in the events queue.
One solution would be to pulse the hotplug queue interrupt after CAS,
when we are sure that the hotplug queue is negotiated. However, this
panics the kernel with sig 11 kernel access of bad area, which suggests
that the kernel wasn't quite ready to handle it.
In my experiments using upstream 4.13 I saw that there is a 'safe time'
to pulse the queue, sometime after CAS and before mounting the root fs,
but I wasn't able to pinpoint it. From QEMU perspective, the last hcall
done (an h_set_mode) is still too early to pulse it and the kernel
panics. Looking at the kernel source I saw that the IRQ handling is
initiated quite early in the init process.
So my question (ok, actually 2 questions):
- Is my analysis correct? Is there an unsafe time to fire a IRQ pulse
before CAS that can break the kernel or am I overlooking/doing something
wrong?
- is there a reliable way to know when can the kernel safely handle the
hotplug interrupt?
Thanks,
Daniel
next reply other threads:[~2017-08-29 20:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 20:43 Daniel Henrique Barboza [this message]
2017-08-29 21:55 ` Question: handling early hotplug interrupts Benjamin Herrenschmidt
2017-08-29 23:53 ` Daniel Henrique Barboza
2017-08-30 6:09 ` Michael Ellerman
2017-08-30 14:37 ` Nathan Fontenot
2017-08-31 9:53 ` Michael Ellerman
2017-08-30 5:59 ` Michael Ellerman
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=e5975dfb-6609-a3b1-7ea7-b9e8fe31b669@linux.vnet.ibm.com \
--to=danielhb@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.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;
as well as URLs for NNTP newsgroup(s).