[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 05/10] xen/arm: vgic-v3: Document the current restrictions

On 21/01/15 12:16, Ian Campbell wrote:
> On Tue, 2015-01-20 at 17:49 +0000, Julien Grall wrote:
>>>>     - 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.
> Understood.
>> Our current implementation (see vgic_v3_rdistr_mmio_write) consider that
>> the redistributor is banked and replicate n-times in the memory.
> IOW instead of having e.g. 8 individual redistributors each vcpu sees
> it's own redistributor 8 times. That does seem a bit dubious.

It's the current behavior. You can see the difference in linux log. The
address of each redistributor is the same.

>> 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.
> Please can you find a spec reference and include it in the clarified
> version of this item.

Rather than the distributor, there is multiple redistributor (one per

I think the section 5.4.1 in the GICv3 should answer to this question:

"Each re-distributor must be allocated at one page for controlling the
overall behavior of the re-distributor and for controlling physical
LPIs. The base address of this page is referred to as RD_base. In
addition, each re-distributor must be also allocated the following
additional pages".


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.