Re: [PATCH 03/17] base: fix order of OF initialization

2017-06-07 Thread Benjamin Herrenschmidt
On Wed, 2017-06-07 at 11:39 -0700, Wesley Terpstra wrote: > It was a while ago that I debugged this. I already reported this bug > to Benjamin Herrenschmidt (now in CC), and I believe he has a patch of > his own to fix the same issue. > > As I understand it, of_core_init sets up

Re: [PATCH 03/17] base: fix order of OF initialization

2017-06-07 Thread Benjamin Herrenschmidt
On Wed, 2017-06-07 at 11:39 -0700, Wesley Terpstra wrote: > It was a while ago that I debugged this. I already reported this bug > to Benjamin Herrenschmidt (now in CC), and I believe he has a patch of > his own to fix the same issue. > > As I understand it, of_core_init sets up

Re: [PATCH 10/16] powerpc: vio: use dev_groups and not dev_attrs for bus_type

2017-06-06 Thread Benjamin Herrenschmidt
On Wed, 2017-06-07 at 07:45 +0200, Greg Kroah-Hartman wrote: > On Wed, Jun 07, 2017 at 09:04:41AM +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote: > > > >   > > > >   static struct device_attribute vio_dev_att

Re: [PATCH 10/16] powerpc: vio: use dev_groups and not dev_attrs for bus_type

2017-06-06 Thread Benjamin Herrenschmidt
On Wed, 2017-06-07 at 07:45 +0200, Greg Kroah-Hartman wrote: > On Wed, Jun 07, 2017 at 09:04:41AM +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote: > > > >   > > > >   static struct device_attribute vio_dev_att

Re: [PATCH 10/16] powerpc: vio: use dev_groups and not dev_attrs for bus_type

2017-06-06 Thread Benjamin Herrenschmidt
On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote: > >   > >   static struct device_attribute vio_dev_attrs[] = { > >    __ATTR_RO(name), > > @@ -1573,6 +1576,13 @@ static struct device_attribute vio_dev_attrs[] = { > >    __ATTR_RO(modalias), > >    __ATTR_NULL > >   }; > >

Re: [PATCH 10/16] powerpc: vio: use dev_groups and not dev_attrs for bus_type

2017-06-06 Thread Benjamin Herrenschmidt
On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote: > >   > >   static struct device_attribute vio_dev_attrs[] = { > >    __ATTR_RO(name), > > @@ -1573,6 +1576,13 @@ static struct device_attribute vio_dev_attrs[] = { > >    __ATTR_RO(modalias), > >    __ATTR_NULL > >   }; > >

Re: [v2] powerpc: handle simultaneous interrupts at once

2017-06-05 Thread Benjamin Herrenschmidt
On Mon, 2017-06-05 at 20:21 +1000, Michael Ellerman wrote: > On Thu, 2017-03-16 at 08:55:45 UTC, Christophe Leroy wrote: > > It often happens to have simultaneous interrupts, for instance > > when having double Ethernet attachment. With the current > > implementation, we suffer the cost of kernel

Re: [v2] powerpc: handle simultaneous interrupts at once

2017-06-05 Thread Benjamin Herrenschmidt
On Mon, 2017-06-05 at 20:21 +1000, Michael Ellerman wrote: > On Thu, 2017-03-16 at 08:55:45 UTC, Christophe Leroy wrote: > > It often happens to have simultaneous interrupts, for instance > > when having double Ethernet attachment. With the current > > implementation, we suffer the cost of kernel

Re: [PATCH 2/5] powerpc/mm: split store_updates_sp() in two parts in do_page_fault()

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 11:39 +0200, Christophe LEROY wrote: > The difference between get_user() and __get_user() is that get_user() > performs an access_ok() in addition. > > Doesn't access_ok() only checks whether addr is below TASK_SIZE to > ensure it is a valid user address ? Do you have a

Re: [PATCH 2/5] powerpc/mm: split store_updates_sp() in two parts in do_page_fault()

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 11:39 +0200, Christophe LEROY wrote: > The difference between get_user() and __get_user() is that get_user() > performs an access_ok() in addition. > > Doesn't access_ok() only checks whether addr is below TASK_SIZE to > ensure it is a valid user address ? Do you have a

Re: [PATCH v9 5/5] i2c: aspeed: added slave support for Aspeed I2C driver

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote: > Added slave support for Aspeed I2C controller. Supports fourteen busses > present in AST24XX and AST25XX BMC SoCs by Aspeed. (Not an issue for merging) Have you looked at a "mode" by which you implement just enough of the slave support

Re: [PATCH v9 5/5] i2c: aspeed: added slave support for Aspeed I2C driver

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote: > Added slave support for Aspeed I2C controller. Supports fourteen busses > present in AST24XX and AST25XX BMC SoCs by Aspeed. (Not an issue for merging) Have you looked at a "mode" by which you implement just enough of the slave support

Re: [PATCH v8 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 02:29 -0700, Brendan Higgins wrote: > > That way you avoid the above lock which is racy, slave activity could > > get in there and trigger an error interrupt clobbering cmd_err for > > example no ? Or am I missing something... > > The slave handler does not touch these

Re: [PATCH v8 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 02:29 -0700, Brendan Higgins wrote: > > That way you avoid the above lock which is racy, slave activity could > > get in there and trigger an error interrupt clobbering cmd_err for > > example no ? Or am I missing something... > > The slave handler does not touch these

Re: [PATCH v9 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins <brendanhigg...@google.com> Reviewed-by: Benjami

Re: [PATCH v9 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-06-02 Thread Benjamin Herrenschmidt
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins Reviewed-by: Benjamin Herrenschmidt ---

Re: [PATCH v8 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-05-30 Thread Benjamin Herrenschmidt
On Wed, 2017-05-24 at 23:49 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. Hi Brendan ! It's getting there :-) I have a few comments mostly about some corner cases below.

Re: [PATCH v8 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-05-30 Thread Benjamin Herrenschmidt
On Wed, 2017-05-24 at 23:49 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. Hi Brendan ! It's getting there :-) I have a few comments mostly about some corner cases below.

Re: [PATCH 4/7] RISC-V: arch/riscv/include

2017-05-23 Thread Benjamin Herrenschmidt
On Tue, 2017-05-23 at 14:55 +0200, Arnd Bergmann wrote: > > + > > +#include > > I would recommend providing your own {read,write}{b,w,l,q}{,_relaxed} > helpers using inline assembly, to prevent the compiler for breaking > up accesses into byte accesses. > > Also, most architectures require to

Re: [PATCH 4/7] RISC-V: arch/riscv/include

2017-05-23 Thread Benjamin Herrenschmidt
On Tue, 2017-05-23 at 14:55 +0200, Arnd Bergmann wrote: > > + > > +#include > > I would recommend providing your own {read,write}{b,w,l,q}{,_relaxed} > helpers using inline assembly, to prevent the compiler for breaking > up accesses into byte accesses. > > Also, most architectures require to

Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

2017-05-23 Thread Benjamin Herrenschmidt
On Mon, 2017-05-22 at 22:16 -0700, Olof Johansson wrote: > The same is true for some other drivers. Actually, I wonder if it > might be just as easy to implement a sbi backend for hvc -- see > hvc_udbg.c for an example where, on power, you have a simple get/put > char hypervisor call in a very

Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

2017-05-23 Thread Benjamin Herrenschmidt
On Mon, 2017-05-22 at 22:16 -0700, Olof Johansson wrote: > The same is true for some other drivers. Actually, I wonder if it > might be just as easy to implement a sbi backend for hvc -- see > hvc_udbg.c for an example where, on power, you have a simple get/put > char hypervisor call in a very

Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

2017-05-22 Thread Benjamin Herrenschmidt
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote: > So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as > ppc has some other legacy "userspace time" code that has to be > maintained as well (I believe there's not code page, just data page > that userspace pulls directly from).

Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

2017-05-22 Thread Benjamin Herrenschmidt
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote: > So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as > ppc has some other legacy "userspace time" code that has to be > maintained as well (I believe there's not code page, just data page > that userspace pulls directly from).

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

2017-05-19 Thread Benjamin Herrenschmidt
On Mon, 2017-05-15 at 16:07 +0300, Ivan Mikhaylov wrote: > +#ifdef CONFIG_FSP2 > +   /* > +    * Prevent a kernel panic caused by unintentionally clearing TCR > +    * watchdog bits.  At this point in the kernel boot, the watchdog has > +    * already been enabled by u-boot.  The

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

2017-05-19 Thread Benjamin Herrenschmidt
On Mon, 2017-05-15 at 16:07 +0300, Ivan Mikhaylov wrote: > +#ifdef CONFIG_FSP2 > +   /* > +    * Prevent a kernel panic caused by unintentionally clearing TCR > +    * watchdog bits.  At this point in the kernel boot, the watchdog has > +    * already been enabled by u-boot.  The

Re: [v3 0/9] parallelized "struct page" zeroing

2017-05-16 Thread Benjamin Herrenschmidt
On Fri, 2017-05-12 at 13:37 -0400, David Miller wrote: > > Right now it is larger, but what I suggested is to add a new optimized > > routine just for this case, which would do STBI for 64-bytes but > > without membar (do membar at the end of memmap_init_zone() and > > deferred_init_memmap() > >

Re: [v3 0/9] parallelized "struct page" zeroing

2017-05-16 Thread Benjamin Herrenschmidt
On Fri, 2017-05-12 at 13:37 -0400, David Miller wrote: > > Right now it is larger, but what I suggested is to add a new optimized > > routine just for this case, which would do STBI for 64-bytes but > > without membar (do membar at the end of memmap_init_zone() and > > deferred_init_memmap() > >

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-05-09 Thread Benjamin Herrenschmidt
On Mon, 2017-05-08 at 16:28 -0700, Brendan Higgins wrote: > > I am curious what everyone thinks about this. It seemed that, earlier > on, people did not like me disabling multi-master mode, but I think > that it would make bus recovery not work as well. Given that, I think > it makes the most

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-05-09 Thread Benjamin Herrenschmidt
On Mon, 2017-05-08 at 16:28 -0700, Brendan Higgins wrote: > > I am curious what everyone thinks about this. It seemed that, earlier > on, people did not like me disabling multi-master mode, but I think > that it would make bus recovery not work as well. Given that, I think > it makes the most

Re: Is iounmap(NULL) safe or not?

2017-05-06 Thread Benjamin Herrenschmidt
On Sat, 2017-05-06 at 01:50 +0300, Alexey Khoroshilov wrote: > Could you please clarify if iounmap(NULL) safe or not. > I guess it would be less errorprone if the answer is architecture independent. I think it's supposed to be and we should fix ppc. Cheers, Ben.

Re: Is iounmap(NULL) safe or not?

2017-05-06 Thread Benjamin Herrenschmidt
On Sat, 2017-05-06 at 01:50 +0300, Alexey Khoroshilov wrote: > Could you please clarify if iounmap(NULL) safe or not. > I guess it would be less errorprone if the answer is architecture independent. I think it's supposed to be and we should fix ppc. Cheers, Ben.

Re: [PATCH] crypto: vmx: Remove dubiously licensed crypto code

2017-05-05 Thread Benjamin Herrenschmidt
On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote: > > So you have an e-mail message from one of the authors of the code. > Andy Polyakov wrote most of the code but there are probably other > contributors who never gave explicit consent for using their code > outside of OpenSSL. The only

Re: [PATCH] crypto: vmx: Remove dubiously licensed crypto code

2017-05-05 Thread Benjamin Herrenschmidt
On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote: > > So you have an e-mail message from one of the authors of the code. > Andy Polyakov wrote most of the code but there are probably other > contributors who never gave explicit consent for using their code > outside of OpenSSL. The only

Re: [PATCH v4 2/2] drivers/serial: Add driver for Aspeed virtual UART

2017-05-02 Thread Benjamin Herrenschmidt
e, as the host may be using this > bit to configure serial output modes, which is independent of whether > the devices has been opened by BMC userspace. > > Signed-off-by: Jeremy Kerr <j...@ozlabs.org> > Signed-off-by: Joel Stanley <j...@jms.id.au> > Acked-by: Rob Herring

Re: [PATCH v4 2/2] drivers/serial: Add driver for Aspeed virtual UART

2017-05-02 Thread Benjamin Herrenschmidt
using this > bit to configure serial output modes, which is independent of whether > the devices has been opened by BMC userspace. > > Signed-off-by: Jeremy Kerr > Signed-off-by: Joel Stanley > Acked-by: Rob Herring Reviewed-by: Benjamin Herrenschmidt > --- > v4: &g

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-25 Thread Benjamin Herrenschmidt
fy the sender by reply e-mail and immediately > delete the e-mail and any attachments without copying or disclosing > the contents. Thank you. > > > -----Original Message- > From: Brendan Higgins [mailto:brendanhigg...@google.com]  > Sent: Tuesday, April 25, 2017 4:32 PM > To: B

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-25 Thread Benjamin Herrenschmidt
fy the sender by reply e-mail and immediately > delete the e-mail and any attachments without copying or disclosing > the contents. Thank you. > > > -----Original Message- > From: Brendan Higgins [mailto:brendanhigg...@google.com]  > Sent: Tuesday, April 25, 2017 4:32 PM &g

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 11:18 -0700, Brendan Higgins wrote: > +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus, > +    struct platform_device *pdev) > +{ Minor nit ... I'm really not fan of those underscores. We use __ functions in some cases in the kernel

Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 11:18 -0700, Brendan Higgins wrote: > +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus, > +    struct platform_device *pdev) > +{ Minor nit ... I'm really not fan of those underscores. We use __ functions in some cases in the kernel

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 11:56 -0700, Brendan Higgins wrote: > > > +struct aspeed_i2c_bus { > > > + struct i2c_adapter  adap; > > > + struct device   *dev; > > > + void __iomem*base; > > > + /* Synchronizes I/O mem access to base. */ > >

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 11:56 -0700, Brendan Higgins wrote: > > > +struct aspeed_i2c_bus { > > > + struct i2c_adapter  adap; > > > + struct device   *dev; > > > + void __iomem*base; > > > + /* Synchronizes I/O mem access to base. */ > >

Re: [PATCH v4 05/11] VAS: Define helpers for access MMIO regions

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 10:25 -0700, Sukadev Bhattiprolu wrote: > which maybe due to this :-) Should I change to pgprot_noncached() for > the MMIO writes? Just use normal ioremap(). > > requires being mapped cachable. Ask Aneesh for a cleaner way of > > doing it too while at it.

Re: [PATCH v4 05/11] VAS: Define helpers for access MMIO regions

2017-04-24 Thread Benjamin Herrenschmidt
On Mon, 2017-04-24 at 10:25 -0700, Sukadev Bhattiprolu wrote: > which maybe due to this :-) Should I change to pgprot_noncached() for > the MMIO writes? Just use normal ioremap(). > > requires being mapped cachable. Ask Aneesh for a cleaner way of > > doing it too while at it.

Re: [PATCH v4 05/11] VAS: Define helpers for access MMIO regions

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > +static void *map_mmio_region(char *name, uint64_t start, int len) > +{ > +   void *map; > + > +   if (!request_mem_region(start, len, name)) { > +   pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n", > +

Re: [PATCH v4 05/11] VAS: Define helpers for access MMIO regions

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > +static void *map_mmio_region(char *name, uint64_t start, int len) > +{ > +   void *map; > + > +   if (!request_mem_region(start, len, name)) { > +   pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n", > +

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > > + p = of_get_property(dn, "vas-id", NULL); > + if (!p) { > + pr_err("VAS: NULL vas-id? %p\n", p); > + return -ENODEV; > + } > + > + vinst->vas_id = of_read_number(p, 1);

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > > + p = of_get_property(dn, "vas-id", NULL); > + if (!p) { > + pr_err("VAS: NULL vas-id? %p\n", p); > + return -ENODEV; > + } > + > + vinst->vas_id = of_read_number(p, 1);

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > +config VAS > +   tristate "IBM Virtual Accelerator Switchboard (VAS)" CONFIG_IBM_VAS or PPC_VAS ... too high risk of collision otherwise Ben.

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

2017-04-24 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote: > +config VAS > +   tristate "IBM Virtual Accelerator Switchboard (VAS)" CONFIG_IBM_VAS or PPC_VAS ... too high risk of collision otherwise Ben.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 16:24 -0600, Jason Gunthorpe wrote: > Basically, all this list processing is a huge overhead compared to > just putting a helper call in the existing sg iteration loop of the > actual op.  Particularly if the actual op is a no-op like no-mmu x86 > would use. Yes, I'm leaning

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 16:24 -0600, Jason Gunthorpe wrote: > Basically, all this list processing is a huge overhead compared to > just putting a helper call in the existing sg iteration loop of the > actual op.  Particularly if the actual op is a no-op like no-mmu x86 > would use. Yes, I'm leaning

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 17:21 -0600, Jason Gunthorpe wrote: > Splitting the sgl is different from iommu batching. > > As an example, an O_DIRECT write of 1 MB with a single 4K P2P page in > the middle. > > The optimum behavior is to allocate a 1MB-4K iommu range and fill it > with the CPU memory.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 17:21 -0600, Jason Gunthorpe wrote: > Splitting the sgl is different from iommu batching. > > As an example, an O_DIRECT write of 1 MB with a single 4K P2P page in > the middle. > > The optimum behavior is to allocate a 1MB-4K iommu range and fill it > with the CPU memory.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 15:22 -0600, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > > > I think this opens an even bigger can of worms.. > > > > No, I don't think it does. You'd only shim when the target page is > > backed by a device, not host memory, and

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 15:22 -0600, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > > > I think this opens an even bigger can of worms.. > > > > No, I don't think it does. You'd only shim when the target page is > > backed by a device, not host memory, and

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote: > I don't follow, when does get_dma_ops() return a p2p aware provider? > It has no way to know if the DMA is going to involve p2p, get_dma_ops > is called with the device initiating the DMA. > > So you'd always return the P2P shim on a

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote: > I don't follow, when does get_dma_ops() return a p2p aware provider? > It has no way to know if the DMA is going to involve p2p, get_dma_ops > is called with the device initiating the DMA. > > So you'd always return the P2P shim on a

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 14:48 -0600, Logan Gunthorpe wrote: > > ...and that dma_map goes through get_dma_ops(), so I don't see the conflict? > > The main conflict is in dma_map_sg which only does get_dma_ops once but > the sg may contain memory of different types. We can handle that in our

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 14:48 -0600, Logan Gunthorpe wrote: > > ...and that dma_map goes through get_dma_ops(), so I don't see the conflict? > > The main conflict is in dma_map_sg which only does get_dma_ops once but > the sg may contain memory of different types. We can handle that in our

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 12:00 -0600, Jason Gunthorpe wrote: > - All platforms can succeed if the PCI devices are under the same >   'segment', but where segments begin is somewhat platform specific >   knowledge. (this is 'same switch' idea Logan has talked about) We also need to be careful whether

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 12:00 -0600, Jason Gunthorpe wrote: > - All platforms can succeed if the PCI devices are under the same >   'segment', but where segments begin is somewhat platform specific >   knowledge. (this is 'same switch' idea Logan has talked about) We also need to be careful whether

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > > ...and

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > > ...and

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Mon, 2017-04-17 at 23:43 -0600, Logan Gunthorpe wrote: > > On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > > Is it ? Again, you create a "concept" the user may have no idea about, > > "p2pmem memory". So now any kind of memory buffer on a device

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-18 Thread Benjamin Herrenschmidt
On Mon, 2017-04-17 at 23:43 -0600, Logan Gunthorpe wrote: > > On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > > Is it ? Again, you create a "concept" the user may have no idea about, > > "p2pmem memory". So now any kind of memory buffer on a device

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-17 Thread Benjamin Herrenschmidt
On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote: > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > h

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-17 Thread Benjamin Herrenschmidt
On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote: > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > h

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-17 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 23:13 -0600, Logan Gunthorpe wrote: > > > > > I'm still not 100% why do you need a "p2mem device" mind you ... > > Well, you don't "need" it but it is a design choice that I think makes a > lot of sense for the following reasons: > > 1) p2pmem is in fact a device on the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-17 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 23:13 -0600, Logan Gunthorpe wrote: > > > > > I'm still not 100% why do you need a "p2mem device" mind you ... > > Well, you don't "need" it but it is a design choice that I think makes a > lot of sense for the following reasons: > > 1) p2pmem is in fact a device on the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote: > > On 16/04/17 09:53 AM, Dan Williams wrote: > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > > context about the physical address in question. I'm thinking you can > > hang bus address translation data off of

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote: > > On 16/04/17 09:53 AM, Dan Williams wrote: > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > > context about the physical address in question. I'm thinking you can > > hang bus address translation data off of

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote: > > I think you need to give other archs a chance to support this with a > > design that considers the offset case as a first class citizen rather > > than an afterthought. > > I'll consider this. Given the fact I can use your existing >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote: > > I think you need to give other archs a chance to support this with a > > design that considers the offset case as a first class citizen rather > > than an afterthought. > > I'll consider this. Given the fact I can use your existing >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 08:53 -0700, Dan Williams wrote: > > Just thinking out loud ... I don't have a firm idea or a design. But > > peer to peer is definitely a problem we need to tackle generically, the > > demand for it keeps coming up. > > ZONE_DEVICE allows you to redirect via

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 08:53 -0700, Dan Williams wrote: > > Just thinking out loud ... I don't have a firm idea or a design. But > > peer to peer is definitely a problem we need to tackle generically, the > > demand for it keeps coming up. > > ZONE_DEVICE allows you to redirect via

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote: > The difference is that there was nothing fundamental in the core > design of pmem + DAX that prevented other archs from growing pmem > support. Indeed. In fact we have work in progress support for pmem on power using experimental HW. > THP

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-16 Thread Benjamin Herrenschmidt
On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote: > The difference is that there was nothing fundamental in the core > design of pmem + DAX that prevented other archs from growing pmem > support. Indeed. In fact we have work in progress support for pmem on power using experimental HW. > THP

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-15 Thread Benjamin Herrenschmidt
On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote: > I'm wondering, since this is limited to support behind a single > switch, if you could have a software-iommu hanging off that switch > device object that knows how to catch and translate the non-zero > offset bus address case. We have

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-15 Thread Benjamin Herrenschmidt
On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote: > I'm wondering, since this is limited to support behind a single > switch, if you could have a software-iommu hanging off that switch > device object that knows how to catch and translate the non-zero > offset bus address case. We have

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-15 Thread Benjamin Herrenschmidt
On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote: > Thanks, Benjamin, for the summary of some of the issues. > > On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > > So I assume the p2p code provides a way to address that too via special > > dma_ops ? Or wrappers ?

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-15 Thread Benjamin Herrenschmidt
On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote: > Thanks, Benjamin, for the summary of some of the issues. > > On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > > So I assume the p2p code provides a way to address that too via special > > dma_ops ? Or wrappers ?

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Fri, 2017-04-14 at 14:04 -0500, Bjorn Helgaas wrote: > I'm a little hesitant about excluding offset support, so I'd like to > hear more about this. > > Is the issue related to PCI BARs that are not completely addressable > by the CPU?  If so, that sounds like a first-class issue that should >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Fri, 2017-04-14 at 14:04 -0500, Bjorn Helgaas wrote: > I'm a little hesitant about excluding offset support, so I'd like to > hear more about this. > > Is the issue related to PCI BARs that are not completely addressable > by the CPU?  If so, that sounds like a first-class issue that should >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote: > > On 13/04/17 10:16 PM, Jason Gunthorpe wrote: > > I'd suggest just detecting if there is any translation in bus > > addresses anywhere and just hard disabling P2P on such systems. > > That's a fantastic suggestion. It simplifies things

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote: > > On 13/04/17 10:16 PM, Jason Gunthorpe wrote: > > I'd suggest just detecting if there is any translation in bus > > addresses anywhere and just hard disabling P2P on such systems. > > That's a fantastic suggestion. It simplifies things

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Fri, 2017-04-14 at 21:37 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote: > > > > On 13/04/17 10:16 PM, Jason Gunthorpe wrote: > > > I'd suggest just detecting if there is any translation in bus > > > addresses

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Fri, 2017-04-14 at 21:37 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote: > > > > On 13/04/17 10:16 PM, Jason Gunthorpe wrote: > > > I'd suggest just detecting if there is any translation in bus > > > addresses

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 22:16 -0600, Jason Gunthorpe wrote: > > Any caller of pci_add_resource_offset() uses CPU addresses different from > > the PCI bus addresses (unless the offset is zero, of course).  All ACPI > > platforms also support this translation (see "translation_offset"), though > > in

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-14 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 22:16 -0600, Jason Gunthorpe wrote: > > Any caller of pci_add_resource_offset() uses CPU addresses different from > > the PCI bus addresses (unless the offset is zero, of course).  All ACPI > > platforms also support this translation (see "translation_offset"), though > > in

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-13 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 15:22 -0600, Logan Gunthorpe wrote: > > On 12/04/17 03:55 PM, Benjamin Herrenschmidt wrote: > > Look at pcibios_resource_to_bus() and pcibios_bus_to_resource(). They > > will perform the conversion between the struct resource content (CPU > > physical

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-13 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 15:22 -0600, Logan Gunthorpe wrote: > > On 12/04/17 03:55 PM, Benjamin Herrenschmidt wrote: > > Look at pcibios_resource_to_bus() and pcibios_bus_to_resource(). They > > will perform the conversion between the struct resource content (CPU > > physical

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

2017-04-12 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > >   #endif > >    mtctr   r12 > >    bctrl > > +/* > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > + * sane value that is set at early boot time, > > + * thereby clearing LPCR_UPRT. > > + * LPCR_UPRT is required if

Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop

2017-04-12 Thread Benjamin Herrenschmidt
On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > >   #endif > >    mtctr   r12 > >    bctrl > > +/* > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > + * sane value that is set at early boot time, > > + * thereby clearing LPCR_UPRT. > > + * LPCR_UPRT is required if

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-12 Thread Benjamin Herrenschmidt
On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-12 Thread Benjamin Herrenschmidt
On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-12 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote: > Hello, > > As discussed at LSF/MM we'd like to present our work to enable > copy offload support in NVMe fabrics RDMA targets. We'd appreciate > some review and feedback from the community on our direction. > This series is not intended

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

2017-04-12 Thread Benjamin Herrenschmidt
On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote: > Hello, > > As discussed at LSF/MM we'd like to present our work to enable > copy offload support in NVMe fabrics RDMA targets. We'd appreciate > some review and feedback from the community on our direction. > This series is not intended

Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

2017-04-11 Thread Benjamin Herrenschmidt
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote: > Ok, point taken. BTW, may I ask you guys to have a look into this > please ? > > https://lkml.org/lkml/2017/4/6/743 > > It is a side effect of this thread (v2), not sure why > on powerpc has to include . Not sure how we ended up

Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

2017-04-11 Thread Benjamin Herrenschmidt
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote: > Ok, point taken. BTW, may I ask you guys to have a look into this > please ? > > https://lkml.org/lkml/2017/4/6/743 > > It is a side effect of this thread (v2), not sure why > on powerpc has to include . Not sure how we ended up

<    4   5   6   7   8   9   10   11   12   13   >