qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL v2 7/8] hw: xilinx-pcie: Add support for Xilinx A


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL v2 7/8] hw: xilinx-pcie: Add support for Xilinx AXI PCIe Controller
Date: Mon, 4 Jun 2018 11:29:47 +0100

On 22 February 2017 at 00:21, Yongbok Kim <address@hidden> wrote:
> From: Paul Burton <address@hidden>
>
> Add support for emulating the Xilinx AXI Root Port Bridge for PCI
> Express as described by Xilinx' PG055 document. This is a PCIe
> controller that can be used with certain series of Xilinx FPGAs, and is
> used on the MIPS Boston board which will make use of this code.
>
> Signed-off-by: Paul Burton <address@hidden>
> address@hidden:
>   removed returning on !level,
>   updated IRQ connection with GPIO logic,
>   moved xilinx_pcie_init() to boston.c
>   replaced stw_le_p() with pci_set_word()
>   and other cosmetic changes]
> Signed-off-by: Yongbok Kim <address@hidden>
> ---

> +static void xilinx_pcie_host_realize(DeviceState *dev, Error **errp)
> +{
> +    PCIHostState *pci = PCI_HOST_BRIDGE(dev);
> +    XilinxPCIEHost *s = XILINX_PCIE_HOST(dev);
> +    SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> +    PCIExpressHost *pex = PCIE_HOST_BRIDGE(dev);
> +
> +    snprintf(s->name, sizeof(s->name), "pcie%u", s->bus_nr);
> +
> +    /* PCI configuration space */
> +    pcie_host_mmcfg_init(pex, s->cfg_size);
> +
> +    /* MMIO region */
> +    memory_region_init(&s->mmio, OBJECT(s), "mmio", UINT64_MAX);
> +    memory_region_set_enabled(&s->mmio, false);
> +
> +    /* dummy I/O region */
> +    memory_region_init_ram(&s->io, OBJECT(s), "io", 16, NULL);
> +    memory_region_set_enabled(&s->io, false);

Hi; I was looking at the code for this PCI controller as
part of identifying RAM memory regions that don't migrate
their contents, and this looks kind of odd. Can you explain
why this is using a RAM region for the PCI bus's IO memory
space? None of our other PCI controller models do this, so
I suspect this is a bug. (The effect would be that PCI IO
accesses to addresses which don't have a PCI BAR mapped there
will behave as reads-as-written, which seems pretty unlikely
to be what the hardware does.)

What is the intended semantics for PCI IO accesses with this
controller? (It seems to only be used with the MIPS boston
board model.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]