All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Hongfei Cheng <hongfei@mperpetuo.com>,
	Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai Mailing List <xenomai@xenomai.org>
Subject: Re: [Xenomai] I-pipe's determinism in handling hardware interrupts when GIC implements "Security Extensions"
Date: Sat, 15 Aug 2015 07:46:10 +0200	[thread overview]
Message-ID: <55CED222.8040901@siemens.com> (raw)
In-Reply-To: <CAKC9m6cKtcwx_tYvWVnqNrFMxxN5=0azmLcqPwzuN_ZBX1Kh8A@mail.gmail.com>

On 2015-08-14 22:38, Hongfei Cheng wrote:
>> If, like I believe,
>> such a "privileged interrupt" is handled by the monitor behind
>> Linux/I-pipe's back, then yes, it will break determinism.
> 
> Do you have any suggestion as to how I-pipe can be improved to work
> with ARM's multiple exception levels in order to ensure determinism on
> ARMv7 (and ARMv8)?

Conceptually, this is fairly similar to the SMM on x86. But, in contrast
to that arch, we tend to have the firmware sources on ARM.

You can check if you actually need the secure monitor on our platform
(it's most often used for PSCI) and disable it (may be trickier on ARMv8
where PSCI is mandatory IIRC) or patch it or the kernel to avoid the
problematic service calls (specifically CPU power control via PSCI).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux


  reply	other threads:[~2015-08-15  5:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 18:51 [Xenomai] I-pipe's determinism in handling hardware interrupts when GIC implements "Security Extensions" Hongfei Cheng
2015-08-13 19:11 ` Gilles Chanteperdrix
2015-08-14 20:38   ` Hongfei Cheng
2015-08-15  5:46     ` Jan Kiszka [this message]
2015-08-18 17:37       ` Hongfei Cheng

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=55CED222.8040901@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=hongfei@mperpetuo.com \
    --cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.