From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
stefano.stabellini@citrix.com
Subject: Re: [PATCH 05/10] xen/arm: vgic-v3: Document the current restrictions
Date: Tue, 20 Jan 2015 17:49:34 +0000 [thread overview]
Message-ID: <54BE952E.6040304@linaro.org> (raw)
In-Reply-To: <1421769643.10440.309.camel@citrix.com>
Hi Ian,
On 20/01/15 16:00, Ian Campbell wrote:
> On Mon, 2015-01-19 at 16:29 +0000, Julien Grall wrote:
>> The current vGIC v3 driver doesn't fully implement GICv3 spec:
>> - GICv3 backward compatibility is not supported (GICD_CTLR.ARE = 0)
>
> I think you meant GICv2 here as you did in the code.
Yes.
> In which case I believe this is optional in the spec, i.e. we can be
> compliant and still not implement this.
>
> That's not to say it isn't desirable, but this is a TODO item, not a
> spec non-conformity issue.
Right, I should rename the section to TODO.
>> - A processor can only access his own redistributor. For buggy
>> assumption, the current code bank the redistributors MMIO.
>
> What assumption? It's not clear if you mean that a foreign redistributor
> should not be accessible and is, or if it should be accessible and
> isn't.
Every redistributor (one per processor) are mapped in distinct MMIO region.
Unlike the distributor, the redistributor is not banked.
Our current implementation (see vgic_v3_rdistr_mmio_write) consider that
the redistributor is banked and replicate n-times in the memory.
If you give a look to the redistributor iniatialization (see Xen and
Linux GICv3 code). The code will go through all the redistributors and
check GICR_TYPER to see if the processor is associated to this
redistributor.
I'm not sure how the redistributor should behave if it's accessed by
another processor. But I'm sure it's wrong to bank it.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-01-20 17:50 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 16:29 [PATCH 00/10] xen/arm: Bug fixes for the vGIC Julien Grall
2015-01-19 16:29 ` [PATCH 01/10] xen/arm: vgic-v3: Correctly set GICD_TYPER.IDbits Julien Grall
2015-01-20 15:34 ` Ian Campbell
2015-01-20 17:16 ` Julien Grall
2015-01-20 15:43 ` Ian Campbell
2015-01-19 16:29 ` [PATCH 02/10] xen/arm: vgic-v3: Correctly set GICD_TYPER.CPUNumber Julien Grall
2015-01-20 15:43 ` Ian Campbell
2015-01-19 16:29 ` [PATCH 03/10] xen/arm: vgic-v3: Correctly handle GICD_CTLR Julien Grall
2015-01-20 15:51 ` Ian Campbell
2015-01-20 17:17 ` Julien Grall
2015-01-19 16:29 ` [PATCH 04/10] xen/arm: vgic-v3: Don't check the size when we ignore the write/read as zero Julien Grall
2015-01-20 15:57 ` Ian Campbell
2015-01-20 17:41 ` Julien Grall
2015-01-20 17:57 ` Ian Campbell
2015-01-20 18:50 ` Julien Grall
2015-01-21 12:11 ` Ian Campbell
2015-01-21 12:28 ` Julien Grall
2015-01-21 12:36 ` Ian Campbell
2015-01-21 12:45 ` Julien Grall
2015-01-21 12:50 ` Ian Campbell
2015-01-20 18:04 ` Julien Grall
2015-01-19 16:29 ` [PATCH 05/10] xen/arm: vgic-v3: Document the current restrictions Julien Grall
2015-01-20 16:00 ` Ian Campbell
2015-01-20 17:49 ` Julien Grall [this message]
2015-01-21 12:16 ` Ian Campbell
2015-01-21 12:33 ` Julien Grall
2015-01-21 12:48 ` Ian Campbell
2015-01-21 13:19 ` Julien Grall
2015-01-22 15:19 ` Julien Grall
2015-01-19 16:29 ` [PATCH 06/10] xen/arm: vgic-v3: Print the domain/vcpu in each message Julien Grall
2015-01-20 16:05 ` Ian Campbell
2015-01-20 17:50 ` Julien Grall
2015-01-19 16:29 ` [PATCH 07/10] xen/arm: vgic-v2: Correctly set GICD_TYPER.CPUNumber Julien Grall
2015-01-20 16:06 ` Ian Campbell
2015-01-19 16:29 ` [PATCH 08/10] xen/arm: vgic-v2: Don't check the size when we ignore the write/read a zero Julien Grall
2015-01-20 16:08 ` Ian Campbell
2015-01-19 16:29 ` [PATCH 09/10] xen/arm: vgic-v2: Take the lock when writing into GICD_CTLR Julien Grall
2015-01-20 16:09 ` Ian Campbell
2015-01-19 16:29 ` [PATCH 10/10] xen/arm: vgic-v2: Print the domain/vcpu in each message Julien Grall
2015-01-20 16:09 ` 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=54BE952E.6040304@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.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 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.