[PATCH] KVM: x86: fix wbinvd_dirty_mask use-after-free

2016-10-21 Thread Ido Yariv
ing freeing of wbinvd_dirty_mask. Cc: sta...@vger.kernel.org Signed-off-by: Ido Yariv <i...@wizery.com> --- arch/x86/kvm/x86.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6c633de..9ec8c1d 100644 --- a/arch/x86/kvm/x86.c +++ b

[PATCH] KVM: x86: fix wbinvd_dirty_mask use-after-free

2016-10-21 Thread Ido Yariv
ing freeing of wbinvd_dirty_mask. Cc: sta...@vger.kernel.org Signed-off-by: Ido Yariv --- arch/x86/kvm/x86.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6c633de..9ec8c1d 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x8

[PATCH v6] net: tcp: Fix a PTO timing granularity issue

2015-05-28 Thread Ido Yariv
und this by setting the timeout to at least 2 jiffies on such systems. The 10ms figure was originally selected based on tests performed with the current implementation and HZ = 1000. Thus, leave the behavior on systems with HZ > 100 unchanged. Signed-off-by: Ido Yariv --- include/net/tcp.h

[PATCH v6] net: tcp: Fix a PTO timing granularity issue

2015-05-28 Thread Ido Yariv
this by setting the timeout to at least 2 jiffies on such systems. The 10ms figure was originally selected based on tests performed with the current implementation and HZ = 1000. Thus, leave the behavior on systems with HZ 100 unchanged. Signed-off-by: Ido Yariv idox.ya...@intel.com --- include/net/tcp.h

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 03:15:26PM -0400, Ido Yariv wrote: > Hi Eric, > > On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote: > > On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote: > > > Hi Eric, > > > > > That's a nice optimi

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote: > On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote: > > Hi Eric, > > > That's a nice optimization ;) > > > > However, I think that with Nicholas Mc Guire's recent changes to > > msecs_t

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 09:23:36AM -0700, Eric Dumazet wrote: > On Wed, 2015-05-27 at 11:23 -0400, Ido Yariv wrote: > > > Signed-off-by: Ido Yariv > > --- > > include/net/tcp.h | 9 + > > net/ipv4/tcp_output.c | 2 +- > > 2 files c

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 07:56:25AM -0700, Eric Dumazet wrote: > On Wed, 2015-05-27 at 10:40 -0400, Ido Yariv wrote: > > > HZ=100 is used on some embedded platforms, so it's still something we > > have to deal with unfortunately.. > > > > Since

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 06:41:17AM -0700, Eric Dumazet wrote: > On Wed, 2015-05-27 at 11:36 +, David Laight wrote: > > From: Of Ido Yariv > > > Sent: 26 May 2015 21:17 > > > The Tail Loss Probe RFC specifies that the PTO value should be set to > >

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote: On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote: Hi Eric, That's a nice optimization ;) However, I think that with Nicholas Mc Guire's recent changes to msecs_to_jiffies (http://marc.info/?l=linux-kernelm

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 07:56:25AM -0700, Eric Dumazet wrote: On Wed, 2015-05-27 at 10:40 -0400, Ido Yariv wrote: HZ=100 is used on some embedded platforms, so it's still something we have to deal with unfortunately.. Since the '2' here is a lower bound, and msecs_to_jiffies

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 06:41:17AM -0700, Eric Dumazet wrote: On Wed, 2015-05-27 at 11:36 +, David Laight wrote: From: Of Ido Yariv Sent: 26 May 2015 21:17 The Tail Loss Probe RFC specifies that the PTO value should be set to max(2 * SRTT, 10ms), where SRTT

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 09:23:36AM -0700, Eric Dumazet wrote: On Wed, 2015-05-27 at 11:23 -0400, Ido Yariv wrote: Signed-off-by: Ido Yariv idox.ya...@intel.com --- include/net/tcp.h | 9 + net/ipv4/tcp_output.c | 2 +- 2 files changed, 10 insertions(+), 1

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-27 Thread Ido Yariv
Hi Eric, On Wed, May 27, 2015 at 03:15:26PM -0400, Ido Yariv wrote: Hi Eric, On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote: On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote: Hi Eric, That's a nice optimization ;) However, I think that with Nicholas Mc

[PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
und this by setting the timeout to at least 2 jiffies on such systems. The 10ms figure was originally selected based on tests performed with the current implementation and HZ = 1000. Thus, leave the behavior on systems with HZ > 100 unchanged. Signed-off-by: Ido Yariv --- net/ipv4/tcp_output.c | 3

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 11:25:21AM -0700, Eric Dumazet wrote: > On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote: > > > > > The platform this was tested on was an embedded platform with a wifi > > module (11n, 20MHZ). The other end was a

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 10:13:40AM -0700, Eric Dumazet wrote: > On Tue, 2015-05-26 at 13:02 -0400, Ido Yariv wrote: > > Hi Eric, > > > > On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote: > > > Have you really hit an issue, or did

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote: > On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote: > > The Tail Loss Probe RFC specifies that the PTO value should be set to > > max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time. > &g

[PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
this issue, increase the number of jiffies by one, ensuring that the timeout won't expire in less than 10ms. Signed-off-by: Ido Yariv --- net/ipv4/tcp_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 534e5fd..6f57d3d 100644

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 10:13:40AM -0700, Eric Dumazet wrote: On Tue, 2015-05-26 at 13:02 -0400, Ido Yariv wrote: Hi Eric, On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote: Have you really hit an issue, or did you send this patch after all these msecs_to_jiffies

[PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
this by setting the timeout to at least 2 jiffies on such systems. The 10ms figure was originally selected based on tests performed with the current implementation and HZ = 1000. Thus, leave the behavior on systems with HZ 100 unchanged. Signed-off-by: Ido Yariv idox.ya...@intel.com --- net/ipv4

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 11:25:21AM -0700, Eric Dumazet wrote: On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote: The platform this was tested on was an embedded platform with a wifi module (11n, 20MHZ). The other end was a computer running Windows, and the benchmarking

[PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
this issue, increase the number of jiffies by one, ensuring that the timeout won't expire in less than 10ms. Signed-off-by: Ido Yariv idox.ya...@intel.com --- net/ipv4/tcp_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index

Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

2015-05-26 Thread Ido Yariv
Hi Eric, On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote: On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote: The Tail Loss Probe RFC specifies that the PTO value should be set to max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time. The PTO value is converted

Re: [PATCHv2 04/10] remoteproc: Parse ELF file to find resource table address

2013-02-24 Thread Ido Yariv
Hi Sjur, On Thu, Feb 21, 2013 at 06:15:34PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Add function find_rsc_table_va to firmware ops. This function > returns the location of the resource table in shared memory > after loading. > > Signed-off-by: Sjur Brændeland

Re: [PATCHv2 04/10] remoteproc: Parse ELF file to find resource table address

2013-02-24 Thread Ido Yariv
Hi Sjur, On Thu, Feb 21, 2013 at 06:15:34PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Add function find_rsc_table_va to firmware ops. This function returns the location of the resource table in shared memory after loading.

Re: [PATCH 9/9] remoteproc: Always perserve resource table data

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:12PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Copy resource table from first to second firmware loading. > After firmware is loaded to memory, update the vdevs resource > pointer to the resource table kept in device memory.

Re: [PATCH 8/9] remoteproc: Calculate max_notifyid by counting vrings

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:11PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Simplify handling of max_notifyid by simply counting the > number of vrings. > > Signed-off-by: Sjur Brændeland > --- > drivers/remoteproc/remoteproc_core.c | 34 >

Re: [PATCH 6/9] remoteproc: Support virtio config space.

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:09PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Support virtio configuration space and device status and > feature negotiation with remote device. This virtio device > can now access the resource table in shared memory. > >

Re: [PATCH 2/9] remoteproc: Refactor function rproc_elf_find_rsc_table

2013-02-20 Thread Ido Yariv
Hi Sjur, Sorry for the (very) late reply. On Sun, Feb 10, 2013 at 12:39:05PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Refactor rproc_elf_find_rsc_table and split out the scanning > for the section header named resource table. This is done to > prepare for

Re: [PATCH 3/9] remoteproc: Parse ELF file to find resource table address

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:06PM +0100, sjur.brandel...@stericsson.com wrote: > From: Sjur Brændeland > > Add function find_rsc_table_va to firmware ops. This function > returns the location of the resource table in shared memory > after loading. > > Signed-off-by: Sjur Brændeland

Re: [PATCH 2/9] remoteproc: Refactor function rproc_elf_find_rsc_table

2013-02-20 Thread Ido Yariv
Hi Sjur, Sorry for the (very) late reply. On Sun, Feb 10, 2013 at 12:39:05PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Refactor rproc_elf_find_rsc_table and split out the scanning for the section header named resource table. This is

Re: [PATCH 3/9] remoteproc: Parse ELF file to find resource table address

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:06PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Add function find_rsc_table_va to firmware ops. This function returns the location of the resource table in shared memory after loading.

Re: [PATCH 6/9] remoteproc: Support virtio config space.

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:09PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Support virtio configuration space and device status and feature negotiation with remote device. This virtio device can now access the resource table

Re: [PATCH 8/9] remoteproc: Calculate max_notifyid by counting vrings

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:11PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Simplify handling of max_notifyid by simply counting the number of vrings. Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com ---

Re: [PATCH 9/9] remoteproc: Always perserve resource table data

2013-02-20 Thread Ido Yariv
Hi Sjur, On Sun, Feb 10, 2013 at 12:39:12PM +0100, sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Copy resource table from first to second firmware loading. After firmware is loaded to memory, update the vdevs resource pointer to the resource

Re: [PATCH] hwspinlock/core: Add testing capabilities

2012-12-30 Thread Ido Yariv
Hi Steve, On Sun, Dec 30, 2012 at 10:13:08PM +0800, steve.zhan wrote: > Hi, >    Acked-by: Steve zhan zhanzhe...@gmail.com >   >    "I'd rather not test the spinlocks after they are registering as they > might already be in use by then." > >     Why? I think user must use it after

Re: [PATCH] hwspinlock/core: Add testing capabilities

2012-12-30 Thread Ido Yariv
Hi Steve, On Sat, Dec 29, 2012 at 05:19:08PM +0800, steve.zhan wrote: > Hi, > > It is good idea add this feature. > > 1: Can we let the "ret = hwspin_lock_tests(ops, hwlock);" add after > hwspin_lock_register_single have return > succeed, that can avoid test duplicated Or error lockid. Of

Re: [PATCH] hwspinlock/core: Add testing capabilities

2012-12-30 Thread Ido Yariv
Hi Steve, On Sat, Dec 29, 2012 at 05:19:08PM +0800, steve.zhan wrote: Hi, It is good idea add this feature. 1: Can we let the ret = hwspin_lock_tests(ops, hwlock); add after hwspin_lock_register_single have return succeed, that can avoid test duplicated Or error lockid. Of course, If

Re: [PATCH] hwspinlock/core: Add testing capabilities

2012-12-30 Thread Ido Yariv
Hi Steve, On Sun, Dec 30, 2012 at 10:13:08PM +0800, steve.zhan wrote: Hi,    Acked-by: Steve zhan zhanzhe...@gmail.com      I'd rather not test the spinlocks after they are registering as they might already be in use by then.     Why? I think user must use it after hwspin_lock_register

Re: [RFCv2 07/11] remoteproc: Register virtio devices after vring allocation

2012-12-21 Thread Ido Yariv
Hi Sjur, On Fri, Dec 21, 2012 at 01:20:02PM +0100, Sjur BRENDELAND wrote: > Hi Ido, > > > From: Ido Yariv [mailto:i...@wizery.com] > > > Postpone the registration of virtio devices until all > > > vritio ring resource has been allocated. > > > This fixe

Re: [RFCv2 05/11] remoteproc: Load firmware once.

2012-12-21 Thread Ido Yariv
Hi Sjur, On Fri, Dec 21, 2012 at 01:02:02PM +0100, Sjur BRENDELAND wrote: > Hi Ido and Ohad, > > > In case the remote processor is added, booted and then rebooted, the > > program sections wont be reinitialized. This can be a bit problematic, > > since the firmware might assume values are

Re: [RFCv2 05/11] remoteproc: Load firmware once.

2012-12-21 Thread Ido Yariv
Hi Sjur, On Fri, Dec 21, 2012 at 01:02:02PM +0100, Sjur BRENDELAND wrote: Hi Ido and Ohad, In case the remote processor is added, booted and then rebooted, the program sections wont be reinitialized. This can be a bit problematic, since the firmware might assume values are initialized in

Re: [RFCv2 07/11] remoteproc: Register virtio devices after vring allocation

2012-12-21 Thread Ido Yariv
Hi Sjur, On Fri, Dec 21, 2012 at 01:20:02PM +0100, Sjur BRENDELAND wrote: Hi Ido, From: Ido Yariv [mailto:i...@wizery.com] Postpone the registration of virtio devices until all vritio ring resource has been allocated. This fixes the following bug: The driver's start callback

Re: [RFCv2 09/11] remoteproc: Add operation to find resource table in memory

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:58PM +0100, Sjur Brændeland wrote: > Add function find_rsc_table_va to firmware ops. This function > returns the location of the resource table in shared memory > after loading. > > Signed-off-by: Sjur Brændeland > --- >

Re: [RFCv2 08/11] remoteproc: Refactor function rproc_elf_find_rsc_table

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:57PM +0100, Sjur Brændeland wrote: > Refatcor rproc_elf_find_rsc_table and split out the scanning Small typo there. > for the section header named resource table. This is done to > prepare for loading firmware once. > > Signed-off-by: Sjur Brændeland

Re: [RFCv2 10/11] remoteproc: Find resource table in device memory

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:59PM +0100, Sjur Brændeland wrote: > Call rproc_get_rsctab_addr() to get the address > of the resource table in shared memory. > > Signed-off-by: Sjur Brændeland This patch should probably be squashed with the next one, since it doesn't do much on its

Re: [RFCv2 07/11] remoteproc: Register virtio devices after vring allocation

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:56PM +0100, Sjur Brændeland wrote: > Postpone the registration of virtio devices until all > vritio ring resource has been allocated. > This fixes the following bug: The driver's start callback > is called before all vring notify ids are allocated and >

Re: [RFCv2 11/11] remoteproc: Support virtio config space.

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:07:00PM +0100, Sjur Brændeland wrote: > Support virtio configuration space and device status and > feature negotiation with remote device. This virtio device > can now access the resource table in shared memory. > > Signed-off-by: Sjur Brændeland > --- ...

Re: [RFCv2 05/11] remoteproc: Load firmware once.

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:54PM +0100, Sjur Brændeland wrote: > Load the firmware once and pave the way for two way > communication of virtio configuration and status bits. > The virtio ring device address is now stored in the resource > table. > > NOTE: This patch requires device

Re: [RFCv2 04/11] remoteproc: Add state RPROC_LOADED

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:53PM +0100, Sjur Brændeland wrote: > Add state RPROC_LOADED as firmware loading and startup will be > different states. > > Signed-off-by: Sjur Brændeland The rproc_state holds the state of the remote processor and it will still be offline even when the

Re: [RFCv2 03/11] remoteproc: Set vring addresses in resource table

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:52PM +0100, Sjur Brændeland wrote: > Set the vring addresses in the resource table so that > the remote device can read the actual addresses used. > > Signed-off-by: Sjur Brændeland Since this new member will only be referenced in the last patch, perhaps

Re: [RFCv2 03/11] remoteproc: Set vring addresses in resource table

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:52PM +0100, Sjur Brændeland wrote: Set the vring addresses in the resource table so that the remote device can read the actual addresses used. Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com Since this new member will only be referenced

Re: [RFCv2 04/11] remoteproc: Add state RPROC_LOADED

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:53PM +0100, Sjur Brændeland wrote: Add state RPROC_LOADED as firmware loading and startup will be different states. Signed-off-by: Sjur Brændeland sjur.brandel...@steicsson.com The rproc_state holds the state of the remote processor and it will still

Re: [RFCv2 05/11] remoteproc: Load firmware once.

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:54PM +0100, Sjur Brændeland wrote: Load the firmware once and pave the way for two way communication of virtio configuration and status bits. The virtio ring device address is now stored in the resource table. NOTE: This patch requires device

Re: [RFCv2 11/11] remoteproc: Support virtio config space.

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:07:00PM +0100, Sjur Brændeland wrote: Support virtio configuration space and device status and feature negotiation with remote device. This virtio device can now access the resource table in shared memory. Signed-off-by: Sjur Brændeland

Re: [RFCv2 07/11] remoteproc: Register virtio devices after vring allocation

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:56PM +0100, Sjur Brændeland wrote: Postpone the registration of virtio devices until all vritio ring resource has been allocated. This fixes the following bug: The driver's start callback is called before all vring notify ids are allocated and

Re: [RFCv2 10/11] remoteproc: Find resource table in device memory

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:59PM +0100, Sjur Brændeland wrote: Call rproc_get_rsctab_addr() to get the address of the resource table in shared memory. Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com This patch should probably be squashed with the next one, since it

Re: [RFCv2 08/11] remoteproc: Refactor function rproc_elf_find_rsc_table

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:57PM +0100, Sjur Brændeland wrote: Refatcor rproc_elf_find_rsc_table and split out the scanning Small typo there. for the section header named resource table. This is done to prepare for loading firmware once. Signed-off-by: Sjur Brændeland

Re: [RFCv2 09/11] remoteproc: Add operation to find resource table in memory

2012-12-20 Thread Ido Yariv
Hi Sjur, On Fri, Dec 14, 2012 at 05:06:58PM +0100, Sjur Brændeland wrote: Add function find_rsc_table_va to firmware ops. This function returns the location of the resource table in shared memory after loading. Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com ---

[PATCH] hwspinlock/core: Fix unbalanced module_get on error path

2012-12-12 Thread Ido Yariv
In case pm_runtime_get_sync() fails, __hwspin_lock_request will exit without calling module_put. As a result, the module could never be removed. Fix this. Signed-off-by: Ido Yariv --- drivers/hwspinlock/hwspinlock_core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git

[PATCH] hwspinlock/core: Add testing capabilities

2012-12-12 Thread Ido Yariv
Add testing capabilities for verifying correctness of the underlying hwspinlock layers. This can be handy especially during development. These tests are performed only once as part of the hwspinlock registration. Signed-off-by: Ido Yariv --- drivers/hwspinlock/Kconfig |9

[PATCH] hwspinlock/core: Add testing capabilities

2012-12-12 Thread Ido Yariv
Add testing capabilities for verifying correctness of the underlying hwspinlock layers. This can be handy especially during development. These tests are performed only once as part of the hwspinlock registration. Signed-off-by: Ido Yariv i...@wizery.com --- drivers/hwspinlock/Kconfig

[PATCH] hwspinlock/core: Fix unbalanced module_get on error path

2012-12-12 Thread Ido Yariv
In case pm_runtime_get_sync() fails, __hwspin_lock_request will exit without calling module_put. As a result, the module could never be removed. Fix this. Signed-off-by: Ido Yariv i...@wizery.com --- drivers/hwspinlock/hwspinlock_core.c |1 + 1 files changed, 1 insertions(+), 0 deletions

Re: WARNING: at vsmp_64.c: is_vsmp_box()

2012-08-23 Thread Ido Yariv
Hi Fengguang, On Thu, Aug 23, 2012 at 08:55:15AM +0800, Fengguang Wu wrote: > Hi Ido, > > The below warning should be introduced by this commit at tip/master: > > commit c00679af441c5be76e195deed2c76fef65a5d102 > Author: Ido Yariv > CommitDate: Wed Aug 22 10:48:05 20

Re: WARNING: at vsmp_64.c: is_vsmp_box()

2012-08-23 Thread Ido Yariv
Hi Fengguang, On Thu, Aug 23, 2012 at 08:55:15AM +0800, Fengguang Wu wrote: Hi Ido, The below warning should be introduced by this commit at tip/master: commit c00679af441c5be76e195deed2c76fef65a5d102 Author: Ido Yariv i...@wizery.com CommitDate: Wed Aug 22 10:48:05 2012 +0200

[PATCH v2] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread Ido Yariv
vSMP Foundation detection and initialization could be done by the hypervisor layer, so set it up that way. Signed-off-by: Ido Yariv Acked-by: Shai Fultheim --- Changes from v1: - Fixed build errors on 32bit kernels arch/x86/include/asm/hypervisor.h |1 + arch/x86/include/asm/setup.h

Re: [PATCH v2 2/2] x86/pat: Avoid contention on cpa_lock if possible

2012-08-22 Thread Ido Yariv
Hi Ingo, On Wed, Aug 22, 2012 at 10:47:02AM +0200, Ingo Molnar wrote: > > * Ido Yariv wrote: > > > vSMP Foundation does not require to serialize CPA by guaranteeing that > > the most recent TLB entry will always be used. > > > > To avoid needless contentio

Re: [tip:x86/platform] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread Ido Yariv
Hi Ingo, On Wed, Aug 22, 2012 at 11:11:41AM +0200, Ingo Molnar wrote: > > * tip-bot for Ido Yariv wrote: > > > Commit-ID: c00679af441c5be76e195deed2c76fef65a5d102 > > Gitweb: > > http://git.kernel.org/tip/c00679af441c5be76e195deed2c76fef65a5d102 > > Auth

[tip:x86/platform] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread tip-bot for Ido Yariv
Commit-ID: c00679af441c5be76e195deed2c76fef65a5d102 Gitweb: http://git.kernel.org/tip/c00679af441c5be76e195deed2c76fef65a5d102 Author: Ido Yariv AuthorDate: Wed, 8 Aug 2012 20:01:38 +0300 Committer: Ingo Molnar CommitDate: Wed, 22 Aug 2012 10:48:05 +0200 x86/vsmp: Use hypervisor layer

[tip:x86/platform] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread tip-bot for Ido Yariv
Commit-ID: c00679af441c5be76e195deed2c76fef65a5d102 Gitweb: http://git.kernel.org/tip/c00679af441c5be76e195deed2c76fef65a5d102 Author: Ido Yariv i...@wizery.com AuthorDate: Wed, 8 Aug 2012 20:01:38 +0300 Committer: Ingo Molnar mi...@kernel.org CommitDate: Wed, 22 Aug 2012 10:48:05 +0200

Re: [tip:x86/platform] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread Ido Yariv
Hi Ingo, On Wed, Aug 22, 2012 at 11:11:41AM +0200, Ingo Molnar wrote: * tip-bot for Ido Yariv i...@wizery.com wrote: Commit-ID: c00679af441c5be76e195deed2c76fef65a5d102 Gitweb: http://git.kernel.org/tip/c00679af441c5be76e195deed2c76fef65a5d102 Author: Ido Yariv i

Re: [PATCH v2 2/2] x86/pat: Avoid contention on cpa_lock if possible

2012-08-22 Thread Ido Yariv
Hi Ingo, On Wed, Aug 22, 2012 at 10:47:02AM +0200, Ingo Molnar wrote: * Ido Yariv i...@wizery.com wrote: vSMP Foundation does not require to serialize CPA by guaranteeing that the most recent TLB entry will always be used. To avoid needless contention on cpa_lock, do not lock/unlock

[PATCH v2] x86/vsmp: Use hypervisor layer for initialization

2012-08-22 Thread Ido Yariv
vSMP Foundation detection and initialization could be done by the hypervisor layer, so set it up that way. Signed-off-by: Ido Yariv i...@wizery.com Acked-by: Shai Fultheim s...@scalemp.com --- Changes from v1: - Fixed build errors on 32bit kernels arch/x86/include/asm/hypervisor.h |1

Re: [PATCH 1/2] vsmp: Use hypervisor layer for initialization

2012-08-19 Thread Ido Yariv
On Wed, Aug 08, 2012 at 08:01:38PM +0300, Ido Yariv wrote: > vSMP Foundation detection and initialization could be done by the > hypervisor layer, so set it up that way. > > Signed-off-by: Ido Yariv > Acked-by: Shai Fultheim > --- Ping? Thanks, Ido. -- To unsubscribe fr

Re: [PATCH 1/2] vsmp: Use hypervisor layer for initialization

2012-08-19 Thread Ido Yariv
On Wed, Aug 08, 2012 at 08:01:38PM +0300, Ido Yariv wrote: vSMP Foundation detection and initialization could be done by the hypervisor layer, so set it up that way. Signed-off-by: Ido Yariv i...@wizery.com Acked-by: Shai Fultheim s...@scalemp.com --- Ping? Thanks, Ido. -- To unsubscribe

[PATCH 1/2] vsmp: Use hypervisor layer for initialization

2012-08-08 Thread Ido Yariv
vSMP Foundation detection and initialization could be done by the hypervisor layer, so set it up that way. Signed-off-by: Ido Yariv Acked-by: Shai Fultheim --- arch/x86/include/asm/hypervisor.h |1 + arch/x86/include/asm/setup.h |7 --- arch/x86/kernel/cpu/hypervisor.c |1

[PATCH v2 2/2] x86/pat: Avoid contention on cpa_lock if possible

2012-08-08 Thread Ido Yariv
vSMP Foundation does not require to serialize CPA by guaranteeing that the most recent TLB entry will always be used. To avoid needless contention on cpa_lock, do not lock/unlock it if it isn't necessary. Based on work by Shai Fultheim . Signed-off-by: Ido Yariv Acked-by: Shai Fultheim

[PATCH v2 2/2] x86/pat: Avoid contention on cpa_lock if possible

2012-08-08 Thread Ido Yariv
vSMP Foundation does not require to serialize CPA by guaranteeing that the most recent TLB entry will always be used. To avoid needless contention on cpa_lock, do not lock/unlock it if it isn't necessary. Based on work by Shai Fultheim s...@scalemp.com. Signed-off-by: Ido Yariv i...@wizery.com

[PATCH 1/2] vsmp: Use hypervisor layer for initialization

2012-08-08 Thread Ido Yariv
vSMP Foundation detection and initialization could be done by the hypervisor layer, so set it up that way. Signed-off-by: Ido Yariv i...@wizery.com Acked-by: Shai Fultheim s...@scalemp.com --- arch/x86/include/asm/hypervisor.h |1 + arch/x86/include/asm/setup.h |7 --- arch/x86