| Message ID | 20140207134252.24451.65306.stgit@bahia.local |
|---|---|
| State | New |
| Headers | show |
On 07.02.2014, at 14:44, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > In the past, IO space could not be mapped into the memory address space > so we introduced a workaround for that. Nowadays it does not look > necessary so we can remove the workaround and make sPAPR PCI > configuration simplier. > > Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Alexey, I would like at least your ack for this. This patch would be the 3rd or 4th attempt to do this shift and every time we saw unexpected breakage :). Alex
On 02/08/2014 01:06 AM, Alexander Graf wrote: > > On 07.02.2014, at 14:44, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > >> In the past, IO space could not be mapped into the memory address space >> so we introduced a workaround for that. Nowadays it does not look >> necessary so we can remove the workaround and make sPAPR PCI >> configuration simplier. >> >> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> > > Alexey, I would like at least your ack for this. This patch would be the 3rd or 4th attempt to do this shift and every time we saw unexpected breakage :). Seems to be all right, cannot find any problem this time :) Thanks! Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru>
On 10.02.14 06:12, Alexey Kardashevskiy wrote: > On 02/08/2014 01:06 AM, Alexander Graf wrote: >> On 07.02.2014, at 14:44, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: >> >>> In the past, IO space could not be mapped into the memory address space >>> so we introduced a workaround for that. Nowadays it does not look >>> necessary so we can remove the workaround and make sPAPR PCI >>> configuration simplier. >>> >>> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> >> Alexey, I would like at least your ack for this. This patch would be the 3rd or 4th attempt to do this shift and every time we saw unexpected breakage :). > > Seems to be all right, cannot find any problem this time :) Thanks! > > Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru> Thanks, applied to ppc-next. Alex
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index 66ddf10..3b7d978 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -564,23 +564,14 @@ static int spapr_phb_init(SysBusDevice *s) memory_region_add_subregion(get_system_memory(), sphb->mem_win_addr, &sphb->memwindow); - /* On ppc, we only have MMIO no specific IO space from the CPU - * perspective. In theory we ought to be able to embed the PCI IO - * memory region direction in the system memory space. However, - * if any of the IO BAR subregions use the old_portio mechanism, - * that won't be processed properly unless accessed from the - * system io address space. This hack to bounce things via - * system_io works around the problem until all the users of - * old_portion are updated */ + /* Initialize IO regions */ sprintf(namebuf, "%s.io", sphb->dtbusname); memory_region_init(&sphb->iospace, OBJECT(sphb), namebuf, SPAPR_PCI_IO_WIN_SIZE); - /* FIXME: fix to support multiple PHBs */ - memory_region_add_subregion(get_system_io(), 0, &sphb->iospace); sprintf(namebuf, "%s.io-alias", sphb->dtbusname); memory_region_init_alias(&sphb->iowindow, OBJECT(sphb), namebuf, - get_system_io(), 0, SPAPR_PCI_IO_WIN_SIZE); + &sphb->iospace, 0, SPAPR_PCI_IO_WIN_SIZE); memory_region_add_subregion(get_system_memory(), sphb->io_win_addr, &sphb->iowindow); /*
In the past, IO space could not be mapped into the memory address space so we introduced a workaround for that. Nowadays it does not look necessary so we can remove the workaround and make sPAPR PCI configuration simplier. Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> --- There has been a previous post for this patch: http://patchwork.ozlabs.org/patch/299123/ Since then, things have evolved: - the kvm_mem_ioeventfd_add failure was fixed by the "KVM: fix addr type for KVM_IOEVENTFD" commit (584f2be). - Alexey's NACK got addressed in SLOF: https://github.com/aik/SLOF/commit/020220e Cheers. -- Greg hw/ppc/spapr_pci.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-)