From: Meador Inge <meador_inge@mentor.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Hollis Blanchard <hollis_blanchard@mentor.com>,
Kushwaha Prabhakar-B32579 <B32579@freescale.com>,
"openmcapi-dev@googlegroups.com" <openmcapi-dev@googlegroups.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/2] powerpc: add support for MPIC message register API
Date: Fri, 06 May 2011 18:51:06 -0500 [thread overview]
Message-ID: <4DC4896A.6010705@mentor.com> (raw)
In-Reply-To: <20110506142937.77e7a10f@schlenkerla.am.freescale.net>
On 05/06/2011 02:29 PM, Scott Wood wrote:
> On Thu, 5 May 2011 16:41:29 -0500
>
> How can both OSes independently own registers 1 and 3 for alloction?
They can't. I just choose a horrible example. It does point to a serious
flaw (which you allude to later) in inferring free registers from send/receive:
in some cases one will have to arbitrarily add registers to send/receive masks
just to keep registers out of the free allocation pool. Your free-mask
proposal is better.
>> So any register mentioned in one of 'mpic-msgr-receive-mask' or
>> 'mpic-msgr-send-mask' is out of the running for general allocation.
>
> mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
> an indication of usage, just that this partition is granted those
> interrupts.
>
> Plus, a dynamically allocated message register must be owned for both
> sending and receiving, so it doesn't make sense to separate it. I'd have
> an "mpic-msgr-free-mask" property, which must be a subset of
> "mpic-msgr-receive-mask". If the register is not in free-mask, it is
> reserved for a fixed purpose. If free-mask is absent, all registers in the
> receive-mask can be allocated.
>
> So the above example would be:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb5 2>;
> mpic-msgr-receive-mask = <0x3>;
> mpic-msgr-free-mask = <0x2>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb1 2 0xb3 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb6 2 0xb7 2>;
> mpic-msgr-receive-mask = <0xc>;
> mpic-msgr-free-mask = <0x8>;
> };
>
> mpic-msgr-send-mask could be added as well, as a permissions mechanism to
> serve as extra protection against an improperly specified non-free message
> register -- especially if the interface is exposed to a less-trusted realm
> such as userspace, or if a hypervisor is reading the device tree to
> determine what to allow guests to do. In this case, just like
> mpic-msgr-receive-mask, it would list both free and non-free message
> registers that the partition can send to, and mpic-msgr-free-mask would be
> a subset of both the send and receive masks.
free-mask seems reasonable. Although, all of these masks are starting to get
rather complicated :-)
Anyway, I am going to cut a v2 patch without the dynamic allocation. All
of this is getting complicated without a public use case. I agree with your
previous suggestion that the dynamic allocation can be added as a part of the
patch set that actually uses it.
Thanks Scott.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
WARNING: multiple messages have this Message-ID (diff)
From: Meador Inge <meador_inge-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Wood Scott-B07421
<B07421-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
Hollis Blanchard
<hollis_blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
"openmcapi-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org"
<openmcapi-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
"linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Subject: Re: [PATCH 2/2] powerpc: add support for MPIC message register API
Date: Fri, 06 May 2011 18:51:06 -0500 [thread overview]
Message-ID: <4DC4896A.6010705@mentor.com> (raw)
In-Reply-To: <20110506142937.77e7a10f-1MYqz8GpK7RekFaExTCHk1jVikpgYyvb5NbjCUgZEJk@public.gmane.org>
On 05/06/2011 02:29 PM, Scott Wood wrote:
> On Thu, 5 May 2011 16:41:29 -0500
>
> How can both OSes independently own registers 1 and 3 for alloction?
They can't. I just choose a horrible example. It does point to a serious
flaw (which you allude to later) in inferring free registers from send/receive:
in some cases one will have to arbitrarily add registers to send/receive masks
just to keep registers out of the free allocation pool. Your free-mask
proposal is better.
>> So any register mentioned in one of 'mpic-msgr-receive-mask' or
>> 'mpic-msgr-send-mask' is out of the running for general allocation.
>
> mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
> an indication of usage, just that this partition is granted those
> interrupts.
>
> Plus, a dynamically allocated message register must be owned for both
> sending and receiving, so it doesn't make sense to separate it. I'd have
> an "mpic-msgr-free-mask" property, which must be a subset of
> "mpic-msgr-receive-mask". If the register is not in free-mask, it is
> reserved for a fixed purpose. If free-mask is absent, all registers in the
> receive-mask can be allocated.
>
> So the above example would be:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb5 2>;
> mpic-msgr-receive-mask = <0x3>;
> mpic-msgr-free-mask = <0x2>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb1 2 0xb3 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb6 2 0xb7 2>;
> mpic-msgr-receive-mask = <0xc>;
> mpic-msgr-free-mask = <0x8>;
> };
>
> mpic-msgr-send-mask could be added as well, as a permissions mechanism to
> serve as extra protection against an improperly specified non-free message
> register -- especially if the interface is exposed to a less-trusted realm
> such as userspace, or if a hypervisor is reading the device tree to
> determine what to allow guests to do. In this case, just like
> mpic-msgr-receive-mask, it would list both free and non-free message
> registers that the partition can send to, and mpic-msgr-free-mask would be
> a subset of both the send and receive masks.
free-mask seems reasonable. Although, all of these masks are starting to get
rather complicated :-)
Anyway, I am going to cut a v2 patch without the dynamic allocation. All
of this is getting complicated without a public use case. I agree with your
previous suggestion that the dynamic allocation can be added as a part of the
patch set that actually uses it.
Thanks Scott.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
next prev parent reply other threads:[~2011-05-06 23:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 16:59 [PATCH 0/2] powerpc: define and implement MPIC message register support Meador Inge
2011-04-19 16:59 ` Meador Inge
2011-04-19 16:59 ` [PATCH 1/2] powerpc: document the FSL MPIC message register binding Meador Inge
2011-04-19 16:59 ` Meador Inge
2011-04-19 17:52 ` Scott Wood
2011-04-19 17:52 ` Scott Wood
2011-04-19 18:26 ` Meador Inge
2011-04-19 18:33 ` Scott Wood
2011-04-21 19:26 ` Meador Inge
2011-04-21 19:26 ` Meador Inge
2011-04-21 19:35 ` Scott Wood
2011-04-21 19:35 ` Scott Wood
2011-04-19 16:59 ` [PATCH 2/2] powerpc: add support for MPIC message register API Meador Inge
2011-04-19 16:59 ` Meador Inge
2011-04-29 5:00 ` Kushwaha Prabhakar-B32579
2011-04-29 5:00 ` Kushwaha Prabhakar-B32579
2011-04-29 16:54 ` Hollis Blanchard
2011-04-29 17:27 ` Kushwaha Prabhakar-B32579
2011-04-29 17:27 ` Kushwaha Prabhakar-B32579
2011-04-29 17:30 ` Scott Wood
2011-04-29 17:30 ` Scott Wood
2011-05-02 3:41 ` Kushwaha Prabhakar-B32579
2011-05-02 3:41 ` Kushwaha Prabhakar-B32579
2011-05-02 16:03 ` Hollis Blanchard
2011-05-03 15:19 ` Scott Wood
2011-05-03 15:19 ` Scott Wood
2011-05-05 21:41 ` Meador Inge
2011-05-06 19:29 ` Scott Wood
2011-05-06 23:51 ` Meador Inge [this message]
2011-05-06 23:51 ` Meador Inge
-- strict thread matches above, loose matches on Subject: below --
2012-02-17 2:49 [PATCH 1/2] powerpc: document the FSL MPIC message register binding Jia Hongtao
2012-02-17 2:49 ` [PATCH 2/2] powerpc: add support for MPIC message register API Jia Hongtao
2012-03-21 17:21 ` Kumar Gala
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=4DC4896A.6010705@mentor.com \
--to=meador_inge@mentor.com \
--cc=B07421@freescale.com \
--cc=B32579@freescale.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=hollis_blanchard@mentor.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=openmcapi-dev@googlegroups.com \
--cc=scottwood@freescale.com \
/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.