Hi! My word...
> What is your guidance, should we introduce new memory maps for GICv3
> enabled machine or should we move to a single dynamic memory map?
IMHO there's no reason to introduce another memory map. I have already done
test integration some time ago, and here is what i got:
--- cut
On 26 May 2015 at 14:07, Eric Auger wrote:
> On 05/26/2015 02:55 PM, Peter Maydell wrote:
>> On 26 May 2015 at 13:54, Eric Auger wrote:
>>> Reviewed-by: Eric Auger
>>>
>>> The only question I have is related to mid-term virt strategy about
>>> GICv3 integration. Are we going to reuse that memory
On 05/26/2015 02:55 PM, Peter Maydell wrote:
> On 26 May 2015 at 13:54, Eric Auger wrote:
>> Reviewed-by: Eric Auger
>>
>> The only question I have is related to mid-term virt strategy about
>> GICv3 integration. Are we going to reuse that memory map for the machine
>> instantiating the GICv3? If
On 26 May 2015 at 13:54, Eric Auger wrote:
> Reviewed-by: Eric Auger
>
> The only question I have is related to mid-term virt strategy about
> GICv3 integration. Are we going to reuse that memory map for the machine
> instantiating the GICv3? If yes, shouldn't we put the GICv2M somewhere
> else t
Reviewed-by: Eric Auger
The only question I have is related to mid-term virt strategy about
GICv3 integration. Are we going to reuse that memory map for the machine
instantiating the GICv3? If yes, shouldn't we put the GICv2M somewhere
else to leave space for GICv3 redistributors, assuming we reu
Hi!
> > Why? The v2m device isn't really related to the GICv3...
> In the future this handle could point to GICv2m or GICv3 ITS or GICv3
> (if I understand it correctly, when it supports message base interrupts
> and no ITS). They all would play the same role of msi-controller.
Yes, exactly. In
Hi Pavel,
On Mon, May 25, 2015 at 04:09:58PM +0300, Pavel Fedin wrote:
> Hello!
>
> > typedef struct MemMapEntry {
> > @@ -88,6 +90,7 @@ typedef struct VirtBoardInfo {
> > int fdt_size;
> > uint32_t clock_phandle;
> > uint32_t gic_phandle;
> > +uint32_t v2m_phandle;
> > } Vi
On 05/25/2015 05:01 PM, Peter Maydell wrote:
> On 25 May 2015 at 14:09, Pavel Fedin wrote:
>> Hello!
>>
>>> typedef struct MemMapEntry {
>>> @@ -88,6 +90,7 @@ typedef struct VirtBoardInfo {
>>> int fdt_size;
>>> uint32_t clock_phandle;
>>> uint32_t gic_phandle;
>>> +uint32_t v
On 25 May 2015 at 14:09, Pavel Fedin wrote:
> Hello!
>
>> typedef struct MemMapEntry {
>> @@ -88,6 +90,7 @@ typedef struct VirtBoardInfo {
>> int fdt_size;
>> uint32_t clock_phandle;
>> uint32_t gic_phandle;
>> +uint32_t v2m_phandle;
>> } VirtBoardInfo;
>
> Could you rename
Hello!
> typedef struct MemMapEntry {
> @@ -88,6 +90,7 @@ typedef struct VirtBoardInfo {
> int fdt_size;
> uint32_t clock_phandle;
> uint32_t gic_phandle;
> +uint32_t v2m_phandle;
> } VirtBoardInfo;
Could you rename v2m_phandle to something more neutral like msi_phandle ? I
Add a GICv2m device to the virt board to enable MSIs on the generic PCI
host controller. We allocate 64 SPIs in the IRQ space for now (this can
be increased/decreased later) and map the GICv2m right after the GIC in
the memory map.
Signed-off-by: Christoffer Dall
---
Changes since v2:
- Factore
11 matches
Mail list logo
