Re: [Qemu-devel] [PATCH v2 3/4] arm: Add PCIe host bridge in virt machine

[Alexander Graf]

On 29.01.15 15:34, Peter Maydell wrote:
> On 29 January 2015 at 14:31, Alexander Graf <address@hidden> wrote:
>>
>>
>> On 27.01.15 17:52, Peter Maydell wrote:
>>> On 21 January 2015 at 16:18, Alexander Graf <address@hidden> wrote:
>>>> +    /* Map the MMIO window at the same spot in bus and cpu layouts */
>>>> +    mmio_alias = g_new0(MemoryRegion, 1);
>>>> +    mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
>>>> +    memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio",
>>>> +                             mmio_reg, base_mmio, size_mmio);
>>>> +    memory_region_add_subregion(get_system_memory(), base_mmio, 
>>>> mmio_alias);
>>>
>>> The comment claims to be mapping the MMIO window twice (in the
>>> system memory space and in the PCI mmio address space) but the
>>> code only seems to be mapping something into system memory space?
>>
>> The comment claims to map it at the same spot. It means the offset in
>> system memory is the same offset as the one in the mmio window that gets
>> exported by the PHB.
>>
>> The PHB exports a UINT64_MAX MMIO region as id 1. This is basically a
>> full window into the PCI address space. What we do here is to map a 1:1
>> window between CPU address space and PCI address space.
> 
> I kind of see, but isn't this just a window from CPU address
> space into PCI address space, not vice-versa?

Yup, exactly. But PCI devices need to map themselves somewhere into the
PCI address space. So if I configure a BAR to live at 0x10000000, it
should also show up at 0x10000000 when accessed from the CPU. That's
what the mapping above is about.

> DMA by PCI devices bus-mastering into system memory must be
> being set up elsewhere, I think.

Yes, that's a different mechanism that's not implemented yet for GPEX
:). On ARM this would happen via SMMU emulation.


Alex