* [Qemu-devel] [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue @ 2010-06-30 10:39 Huacai Chen 2010-06-30 13:38 ` [Qemu-devel] " Isaku Yamahata 0 siblings, 1 reply; 6+ messages in thread From: Huacai Chen @ 2010-06-30 10:39 UTC (permalink / raw) To: mst; +Cc: yamahata, qemu-devel, aurelien, Huacai Chen It seems like software may both use CPU address or PCI address to access a PCI device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make this patch to make both cases works. However, I don't know whether the modification will break other archs, so request for comments here. Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> --- hw/pci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pci.c b/hw/pci.c index 7787005..50e3572 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, target_phys_addr_t addr) { - return addr + bus->mem_base; + return addr | bus->mem_base; } static void pci_unregister_io_regions(PCIDevice *pci_dev) -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue 2010-06-30 10:39 [Qemu-devel] [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue Huacai Chen @ 2010-06-30 13:38 ` Isaku Yamahata 2010-06-30 14:05 ` chen huacai 0 siblings, 1 reply; 6+ messages in thread From: Isaku Yamahata @ 2010-06-30 13:38 UTC (permalink / raw) To: Huacai Chen; +Cc: qemu-devel, aurelien, mst Can you elaborate on how pci bus is mapped into local bus? Is there specification publicly available? Google didn't tell me. On Wed, Jun 30, 2010 at 06:39:53PM +0800, Huacai Chen wrote: > It seems like software may both use CPU address or PCI address to access a PCI > device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ > 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use > 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't > work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make > this patch to make both cases works. > > However, I don't know whether the modification will break other archs, so > request for comments here. > > Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> > --- > hw/pci.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/pci.c b/hw/pci.c > index 7787005..50e3572 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, > static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, > target_phys_addr_t addr) > { > - return addr + bus->mem_base; > + return addr | bus->mem_base; > } > > static void pci_unregister_io_regions(PCIDevice *pci_dev) > -- > 1.7.0.4 > -- yamahata ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue 2010-06-30 13:38 ` [Qemu-devel] " Isaku Yamahata @ 2010-06-30 14:05 ` chen huacai 2010-07-02 2:11 ` Isaku Yamahata 0 siblings, 1 reply; 6+ messages in thread From: chen huacai @ 2010-06-30 14:05 UTC (permalink / raw) To: Isaku Yamahata; +Cc: qemu-devel, aurelien, mst Maybe this is what you want, please look at Page 10. http://people.openrays.org/~comcat/godson/doc/godson2e.north.bridge.manual.pdf But it is written in Chinese, I'm sorry that I also don't have an English version. On Wed, Jun 30, 2010 at 9:38 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > Can you elaborate on how pci bus is mapped into local bus? > Is there specification publicly available? Google didn't tell me. > > > On Wed, Jun 30, 2010 at 06:39:53PM +0800, Huacai Chen wrote: >> It seems like software may both use CPU address or PCI address to access a PCI >> device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ >> 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use >> 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't >> work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make >> this patch to make both cases works. >> >> However, I don't know whether the modification will break other archs, so >> request for comments here. >> >> Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> >> --- >> hw/pci.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/hw/pci.c b/hw/pci.c >> index 7787005..50e3572 100644 >> --- a/hw/pci.c >> +++ b/hw/pci.c >> @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, >> static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, >> target_phys_addr_t addr) >> { >> - return addr + bus->mem_base; >> + return addr | bus->mem_base; >> } >> >> static void pci_unregister_io_regions(PCIDevice *pci_dev) >> -- >> 1.7.0.4 >> > > -- > yamahata > -- Huacai Chen ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Re: [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue 2010-06-30 14:05 ` chen huacai @ 2010-07-02 2:11 ` Isaku Yamahata [not found] ` <AANLkTilli02u9jZ52c0aoTBs-JSEY_mYDwqt2GyeKoYw@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Isaku Yamahata @ 2010-07-02 2:11 UTC (permalink / raw) To: chen huacai; +Cc: qemu-devel, aurelien, mst Thank you the pointer. I found the followings. https://groups.google.com/group/archlinux-for-loongson/web/loongson https://groups.google.com/group/archlinux-for-loongson/web/bonito64-spec.pdf Am I referring to a correct spec? According to it, [0x00000000, 0x10000000) RAM [0x10000000, 0x14000000) PCI_Lo0 [0x14000000, 0x18000000) PCI_Lo1 [0x18000000, 0x1c000000) PCI_Lo2 [0x20000000, 0x80000000) PCI_1.5 [0x80000000, 0x100000000) PCI_2 [0x00000000, 0x0c000000) in physical address is RAM, so I don't understand PMON uses the area. I may be misunderstanding something. Can you elaborate please? PCI_Lo[123] is interesting. The base address can be programmed independently. Such operation isn't assumed by qemu. On Wed, Jun 30, 2010 at 10:05:55PM +0800, chen huacai wrote: > Maybe this is what you want, please look at Page 10. > http://people.openrays.org/~comcat/godson/doc/godson2e.north.bridge.manual.pdf > But it is written in Chinese, I'm sorry that I also don't have an > English version. > > > On Wed, Jun 30, 2010 at 9:38 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > > Can you elaborate on how pci bus is mapped into local bus? > > Is there specification publicly available? Google didn't tell me. > > > > > > On Wed, Jun 30, 2010 at 06:39:53PM +0800, Huacai Chen wrote: > >> It seems like software may both use CPU address or PCI address to access a PCI > >> device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ > >> 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use > >> 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't > >> work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make > >> this patch to make both cases works. > >> > >> However, I don't know whether the modification will break other archs, so > >> request for comments here. > >> > >> Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> > >> --- > >> ??hw/pci.c | ?? ??2 +- > >> ??1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/hw/pci.c b/hw/pci.c > >> index 7787005..50e3572 100644 > >> --- a/hw/pci.c > >> +++ b/hw/pci.c > >> @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, > >> ??static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, > >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??target_phys_addr_t addr) > >> ??{ > >> - ?? ??return addr + bus->mem_base; > >> + ?? ??return addr | bus->mem_base; > >> ??} > >> > >> ??static void pci_unregister_io_regions(PCIDevice *pci_dev) > >> -- > >> 1.7.0.4 > >> > > > > -- > > yamahata > > > > > > -- > Huacai Chen > -- yamahata ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <AANLkTilli02u9jZ52c0aoTBs-JSEY_mYDwqt2GyeKoYw@mail.gmail.com>]
[parent not found: <20100702101318.GD16712@valinux.co.jp>]
* Re: [Qemu-devel] Re: [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue [not found] ` <20100702101318.GD16712@valinux.co.jp> @ 2010-07-03 4:11 ` chen huacai 2010-07-04 13:42 ` Isaku Yamahata 0 siblings, 1 reply; 6+ messages in thread From: chen huacai @ 2010-07-03 4:11 UTC (permalink / raw) To: Isaku Yamahata; +Cc: qemu-devel I have some doubts: when newcfg=0, Qemu Monitor shows BAR6: 32bit memory at 0x04000000 [0x0400ffff] Does this means the physical address 0x04000000 isn't in RAM but in PCI memory? If yes, seems like it will cause problems. If no, how to understand the output of "info pci" in Qemu Monitor? On Fri, Jul 2, 2010 at 6:13 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > On Fri, Jul 02, 2010 at 03:44:05PM +0800, chen huacai wrote: >> Maybe I made some mistakes, or maybe PMON has bugs. :) >> >> Please see the PMON code online at >> http://www.loongson.cn/svn/pmon-loongson/trunk/Targets/Bonito2edev/pci/pci_machdep.c >> In function _pci_hwinit(), if newcfg=0, PMON will use [0x00000000, >> 0x0c000000) to fill BONITO_PCIMAP register. > > Oh I see. You're talking about pci bus address. > > >> When boot to PMON (newcfg=0), I'll see something like this in Qemu Monitor >> BAR6: 32bit memory at 0x04000000 [0x0400ffff] >> Then, after linux kernel loaded, Qemu Monitor shows: >> BAR6: 32bit memory at 0x14000000 [0x1400ffff] > > Do you mean that Linux kernel reprograms BONITO_PCIMAP? > I.e. > PMON maps [0x04000000, 0x0c000000) as Lo[123]in pci bus address with newcfg = 0, > [0x00000000, 0x04000000) as Lo0, [0x14000000, 0x1c000000) as Lo[12] with newcfg = 1. > Linux maps [0x10000000, 0x1c000000) as Lo[123]. > > Then what you want is remapping, not changing pci_to_cpu_addr(). > When pcimap register is modified, update the mapping. > Probably pci_bridge_update_mappings() would help, > > PMON's non-contiguous mapping (newcfg = 1) is challenging, > newcfg = 0 case would be easier. > > >> >> If rebuild PMON with newcfg=1, Qemu Monitor show the same info before >> and after kernel loaded: >> BAR6: 32bit memory at 0x14000000 [0x1400ffff] >> >> On Fri, Jul 2, 2010 at 10:11 AM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: >> > Thank you the pointer. I found the followings. >> > https://groups.google.com/group/archlinux-for-loongson/web/loongson >> > https://groups.google.com/group/archlinux-for-loongson/web/bonito64-spec.pdf >> > Am I referring to a correct spec? >> > >> > According to it, >> > [0x00000000, ??0x10000000) RAM >> > [0x10000000, ??0x14000000) PCI_Lo0 >> > [0x14000000, ??0x18000000) PCI_Lo1 >> > [0x18000000, ??0x1c000000) PCI_Lo2 >> > [0x20000000, ??0x80000000) PCI_1.5 >> > [0x80000000, 0x100000000) PCI_2 >> > >> > [0x00000000, 0x0c000000) in physical address is RAM, so I don't understand PMON uses >> > the area. I may be misunderstanding something. >> > Can you elaborate please? >> > >> > PCI_Lo[123] is interesting. The base address can be programmed independently. >> > Such operation isn't assumed by qemu. >> > >> > >> > On Wed, Jun 30, 2010 at 10:05:55PM +0800, chen huacai wrote: >> >> Maybe this is what you want, please look at Page 10. >> >> http://people.openrays.org/~comcat/godson/doc/godson2e.north.bridge.manual.pdf >> >> But it is written in Chinese, I'm sorry that I also don't have an >> >> English version. >> >> >> >> >> >> On Wed, Jun 30, 2010 at 9:38 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: >> >> > Can you elaborate on how pci bus is mapped into local bus? >> >> > Is there specification publicly available? Google didn't tell me. >> >> > >> >> > >> >> > On Wed, Jun 30, 2010 at 06:39:53PM +0800, Huacai Chen wrote: >> >> >> It seems like software may both use CPU address or PCI address to access a PCI >> >> >> device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ >> >> >> 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use >> >> >> 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't >> >> >> work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make >> >> >> this patch to make both cases works. >> >> >> >> >> >> However, I don't know whether the modification will break other archs, so >> >> >> request for comments here. >> >> >> >> >> >> Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> >> >> >> --- >> >> >> ??hw/pci.c | ?? ??2 +- >> >> >> ??1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> >> >> >> diff --git a/hw/pci.c b/hw/pci.c >> >> >> index 7787005..50e3572 100644 >> >> >> --- a/hw/pci.c >> >> >> +++ b/hw/pci.c >> >> >> @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, >> >> >> ??static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, >> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??target_phys_addr_t addr) >> >> >> ??{ >> >> >> - ?? ??return addr + bus->mem_base; >> >> >> + ?? ??return addr | bus->mem_base; >> >> >> ??} >> >> >> >> >> >> ??static void pci_unregister_io_regions(PCIDevice *pci_dev) >> >> >> -- >> >> >> 1.7.0.4 >> >> >> >> >> > >> >> > -- >> >> > yamahata >> >> > >> >> >> >> >> >> >> >> -- >> >> Huacai Chen >> >> >> > >> > -- >> > yamahata >> > >> >> >> >> -- >> Huacai Chen >> > > -- > yamahata > -- Huacai Chen ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Re: [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue 2010-07-03 4:11 ` chen huacai @ 2010-07-04 13:42 ` Isaku Yamahata 0 siblings, 0 replies; 6+ messages in thread From: Isaku Yamahata @ 2010-07-04 13:42 UTC (permalink / raw) To: chen huacai; +Cc: qemu-devel You're confusing pci bus address with physical address. BAR is pci bus address. On Sat, Jul 03, 2010 at 12:11:58PM +0800, chen huacai wrote: > I have some doubts: when newcfg=0, Qemu Monitor shows > BAR6: 32bit memory at 0x04000000 [0x0400ffff] > Does this means the physical address 0x04000000 isn't in RAM but in PCI memory? > If yes, seems like it will cause problems. > If no, how to understand the output of "info pci" in Qemu Monitor? > > On Fri, Jul 2, 2010 at 6:13 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > > On Fri, Jul 02, 2010 at 03:44:05PM +0800, chen huacai wrote: > >> Maybe I made some mistakes, or maybe PMON has bugs. :) > >> > >> Please see the PMON code online at > >> http://www.loongson.cn/svn/pmon-loongson/trunk/Targets/Bonito2edev/pci/pci_machdep.c > >> In function _pci_hwinit(), if newcfg=0, PMON will use [0x00000000, > >> 0x0c000000) to fill BONITO_PCIMAP register. > > > > Oh I see. You're talking about pci bus address. > > > > > >> When boot to PMON (newcfg=0), I'll see something like this in Qemu Monitor > >> BAR6: 32bit memory at 0x04000000 [0x0400ffff] > >> Then, after linux kernel loaded, Qemu Monitor shows: > >> BAR6: 32bit memory at 0x14000000 [0x1400ffff] > > > > Do you mean that Linux kernel reprograms BONITO_PCIMAP? > > I.e. > > PMON maps [0x04000000, 0x0c000000) as Lo[123]in pci bus address with newcfg = 0, > > ?? ?? ?? ?? ??[0x00000000, 0x04000000) as Lo0, [0x14000000, 0x1c000000) as Lo[12] with newcfg = 1. > > Linux maps [0x10000000, 0x1c000000) as Lo[123]. > > > > Then what you want is remapping, not changing pci_to_cpu_addr(). > > When pcimap register is modified, update the mapping. > > Probably pci_bridge_update_mappings() would help, > > > > PMON's non-contiguous mapping (newcfg = 1) is challenging, > > newcfg = 0 case would be easier. > > > > > >> > >> If rebuild PMON with newcfg=1, Qemu Monitor show the same info before > >> and after kernel loaded: > >> BAR6: 32bit memory at 0x14000000 [0x1400ffff] > >> > >> On Fri, Jul 2, 2010 at 10:11 AM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > >> > Thank you the pointer. I found the followings. > >> > https://groups.google.com/group/archlinux-for-loongson/web/loongson > >> > https://groups.google.com/group/archlinux-for-loongson/web/bonito64-spec.pdf > >> > Am I referring to a correct spec? > >> > > >> > According to it, > >> > [0x00000000, ??0x10000000) RAM > >> > [0x10000000, ??0x14000000) PCI_Lo0 > >> > [0x14000000, ??0x18000000) PCI_Lo1 > >> > [0x18000000, ??0x1c000000) PCI_Lo2 > >> > [0x20000000, ??0x80000000) PCI_1.5 > >> > [0x80000000, 0x100000000) PCI_2 > >> > > >> > [0x00000000, 0x0c000000) in physical address is RAM, so I don't understand PMON uses > >> > the area. I may be misunderstanding something. > >> > Can you elaborate please? > >> > > >> > PCI_Lo[123] is interesting. The base address can be programmed independently. > >> > Such operation isn't assumed by qemu. > >> > > >> > > >> > On Wed, Jun 30, 2010 at 10:05:55PM +0800, chen huacai wrote: > >> >> Maybe this is what you want, please look at Page 10. > >> >> http://people.openrays.org/~comcat/godson/doc/godson2e.north.bridge.manual.pdf > >> >> But it is written in Chinese, I'm sorry that I also don't have an > >> >> English version. > >> >> > >> >> > >> >> On Wed, Jun 30, 2010 at 9:38 PM, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > >> >> > Can you elaborate on how pci bus is mapped into local bus? > >> >> > Is there specification publicly available? Google didn't tell me. > >> >> > > >> >> > > >> >> > On Wed, Jun 30, 2010 at 06:39:53PM +0800, Huacai Chen wrote: > >> >> >> It seems like software may both use CPU address or PCI address to access a PCI > >> >> >> device. For example, Bonito north bridge map PCI memory space at 0x10000000 ~ > >> >> >> 0x1C000000. PMON code use 0x00000000 ~ 0x0C000000, but Linux kernel code use > >> >> >> 0x10000000 ~ 0x1C000000 to access devices. If set pci_mem_base to 0, PMON can't > >> >> >> work, but if set pci_mem_base to 0x10000000, Linux can't access PCI. So I make > >> >> >> this patch to make both cases works. > >> >> >> > >> >> >> However, I don't know whether the modification will break other archs, so > >> >> >> request for comments here. > >> >> >> > >> >> >> Signed-off-by: Huacai Chen <zltjiangshi@gmail.com> > >> >> >> --- > >> >> >> ??hw/pci.c | ?? ??2 +- > >> >> >> ??1 files changed, 1 insertions(+), 1 deletions(-) > >> >> >> > >> >> >> diff --git a/hw/pci.c b/hw/pci.c > >> >> >> index 7787005..50e3572 100644 > >> >> >> --- a/hw/pci.c > >> >> >> +++ b/hw/pci.c > >> >> >> @@ -672,7 +672,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name, > >> >> >> ??static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus, > >> >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??target_phys_addr_t addr) > >> >> >> ??{ > >> >> >> - ?? ??return addr + bus->mem_base; > >> >> >> + ?? ??return addr | bus->mem_base; > >> >> >> ??} > >> >> >> > >> >> >> ??static void pci_unregister_io_regions(PCIDevice *pci_dev) > >> >> >> -- > >> >> >> 1.7.0.4 > >> >> >> > >> >> > > >> >> > -- > >> >> > yamahata > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Huacai Chen > >> >> > >> > > >> > -- > >> > yamahata > >> > > >> > >> > >> > >> -- > >> Huacai Chen > >> > > > > -- > > yamahata > > > > > > -- > Huacai Chen > -- yamahata ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-07-04 13:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-30 10:39 [Qemu-devel] [RFC][PATCH] PCI: fix pci_to_cpu_addr() issue Huacai Chen
2010-06-30 13:38 ` [Qemu-devel] " Isaku Yamahata
2010-06-30 14:05 ` chen huacai
2010-07-02 2:11 ` Isaku Yamahata
[not found] ` <AANLkTilli02u9jZ52c0aoTBs-JSEY_mYDwqt2GyeKoYw@mail.gmail.com>
[not found] ` <20100702101318.GD16712@valinux.co.jp>
2010-07-03 4:11 ` chen huacai
2010-07-04 13:42 ` Isaku Yamahata
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).