[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:48, Ian Campbell wrote:
> On Wed, 2015-01-21 at 12:33 +0000, Julien Grall wrote:
>> 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.
> Are you sure that isn't the "redistributor region"? One of those can
> contain multiple redistributors, i.e. gic_v3_init sets up a single
> region and that propagates to the DTB given to the guest.
> So the error is just in the mmio decode stage I think, not in the setup
> we are trying to achieve.

Right, the device tree is valid, we expose a region containing enough
space for up to 8 distributor.
The problem is in our MMIO emulation.

>>>> 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
>> processor).
>> 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".
> That doesn't say anything about one CPU touching another's
> redistributor.

Linux is at least using GICR_TYPER, to retrieve the right distributor.
For the other the register I've no idea. I've asked ARM. Let see what
they will answer.

Julien Grall

Xen-devel mailing list



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