From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: stefano.stabellini@eu.citrix.com
Subject: Re: [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank
Date: Thu, 8 Oct 2015 10:39:04 +0100 [thread overview]
Message-ID: <1444297144.1410.121.camel@citrix.com> (raw)
In-Reply-To: <56156EDE.8020209@citrix.com>
On Wed, 2015-10-07 at 20:13 +0100, Julien Grall wrote:
> On 07/10/15 17:29, Julien Grall wrote:
> > TBH, I don't see how I can justify that what we are doing is fine except
> > by saying "for simplicity".
I think it is also fine to say that we currently expect that in reality
OSes won't rely on being able to read-back from this register.
> I though a bit more about it. We are both interpreting the spec
> differently and I think both are valid. So hardware people and OS
> developer may also lean toward one of them.
TBH I don't agree, your definition essentially turns any RW register which
does not specify precisely otherwise into a WO register.
> Mine is more restrictive than yours, as you said on v1, it would hit
> picky OS that follow your interpretation and read back the register to
> check either the value is exactly the one written and/or the previous
> value. Although it make the implementation simpler and save memory.
>
> How about:
>
> "Note that with these changes, any read to those registers will list
> only the target vCPU used by Xen. As the spec is not clear whether this
> is a valid choice or not, picky OSes (i.e which read back register to
> check the value written) which have a different interpretation of the
> spec may not boot anymore on Xen. Although, I think this is a fair trade
> between memory usage in Xen (1KB on a domain using 4 vCPUs with no SPIs)
> and a strict interpretation of the spec (though all the cases are not
> clearly defined)".
That's OK. I'd prefer to drop the "picky" and to make the "(i.e. ....)" in
the middle to say something like "(i.e. OSes which perform read-modify
-write operations on these registers"), which is not a picky thing to want
to do even if we don't expect any OS to actually to it.
BTW, IHI 0069A says 8.9.17:
When affinity routing is not enabled, holds the list of target PEs for
the interrupt. That is, it holds the list of CPU interfaces to which the
Distributor forwards the interrupt if it is asserted and has sufficient
priority.
Which isn't actually inconsistent with the register reading back the set of
CPUs to which the interrupt is actually going to end up being routed (i.e.
the behaviour of this patch).
However I think this has gone on long enough and some text which says it
isn't clear is still a reasonable thing to write.
Ian.
next prev parent reply other threads:[~2015-10-08 9:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 14:41 [PATCH v3 0/9] xen/arm: vgic: Support 32-bit access for 64-bit register Julien Grall
2015-10-07 14:41 ` [PATCH v3 1/9] xen/arm: io: remove mmio_check_t typedef Julien Grall
2015-10-07 14:41 ` [PATCH v3 2/9] xen/arm: io: Extend write/read handler to pass the register in parameter Julien Grall
2015-10-07 14:41 ` [PATCH v3 3/9] xen/arm: io: Support sign-extension for every read access Julien Grall
2015-10-07 14:41 ` [PATCH v3 4/9] xen/arm: vgic: ctlr stores a 32-bit hardware register so use uint32_t Julien Grall
2015-10-07 14:41 ` [PATCH v3 5/9] xen/arm: vgic: Optimize the way to store GICD_IPRIORITYR in the rank Julien Grall
2015-10-07 14:41 ` [PATCH v3 6/9] xen/arm: vgic: Introduce a new field to store the rank index and use it Julien Grall
2015-10-07 14:41 ` [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank Julien Grall
2015-10-07 15:38 ` Ian Campbell
2015-10-07 15:48 ` Julien Grall
2015-10-07 16:00 ` Ian Campbell
2015-10-07 16:29 ` Julien Grall
2015-10-07 19:13 ` Julien Grall
2015-10-08 9:39 ` Ian Campbell [this message]
2015-10-08 10:43 ` Julien Grall
2015-10-07 17:26 ` Stefano Stabellini
2015-10-07 18:16 ` Julien Grall
2015-10-08 10:56 ` Ian Campbell
2015-10-08 11:36 ` Stefano Stabellini
2015-10-08 12:23 ` Ian Campbell
2015-10-08 12:34 ` Stefano Stabellini
2015-10-08 13:46 ` Julien Grall
2015-10-08 14:25 ` Ian Campbell
2015-10-08 18:36 ` Julien Grall
2015-10-09 11:24 ` Julien Grall
2015-10-09 11:38 ` Ian Campbell
2015-10-12 10:41 ` Stefano Stabellini
2015-10-12 11:00 ` Julien Grall
2015-10-12 11:07 ` Stefano Stabellini
2015-10-12 11:28 ` Julien Grall
2015-10-07 14:41 ` [PATCH v3 8/9] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register Julien Grall
2015-10-07 14:41 ` [PATCH v3 9/9] xen/arm: vgic-v3: Support 32-bit access for 64-bit registers Julien Grall
2015-10-08 10:44 ` [PATCH v3 0/9] xen/arm: vgic: Support 32-bit access for 64-bit register Julien Grall
2015-10-08 11:46 ` Ian Campbell
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=1444297144.1410.121.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--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;
as well as URLs for NNTP newsgroup(s).