On Fri, 3 May 2013 10:28:02 +0400
Alexander Popov wrote:
> Hello Vinod,
>
> Thanks for the review.
> I will return with improved and tested version 2.
Note that there is a patch for .device_prep_slave_sg() operation
for this driver as part of this series:
https://patchwork.kernel.org/patch/2368
On Fri, 2013-05-03 at 14:52 +1000, David Gibson wrote:
> Here, specifically, the fact that PAGE_BUSY is in PAGE_THP_HPTEFLAGS
> is likely to be bad. If the page is busy, it's in the middle of
> update so can't stably be considered the same as anything.
_PAGE_BUSY is more like a read lock. It mean
> Did someone fix btrfs, but not check other kernel locks? Having now
> hit the same problem again, have you checked that other kernel locks
> don't have adjacent bit fields in the same 64-bit word? And comment
> the struct to ensure someone doesn't optimize those unsigned chars
> back to bit fie
Hello Anatolij,
> Note that there is a patch for .device_prep_slave_sg() operation
> for this driver as part of this series:
> https://patchwork.kernel.org/patch/2368581/
> https://patchwork.kernel.org/patch/2368591/
Thanks, I haven't seen that patch.
It's certainly what my SCLPC device driver nee
On 05/03/2013 03:40 AM, Tony Breeds wrote:
> On Thu, May 02, 2013 at 12:21:37PM -0300, Kleber Sacilotto de Souza wrote:
>
>> Hi Tony,
>>
>> It seems Lucas' change is a bit incomplete and is not handling the reference
>> counter to
>> the device_node correctly. Is the following change what you had
On Fri, May 03, 2013 at 06:19:03PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-05-03 at 14:52 +1000, David Gibson wrote:
> > Here, specifically, the fact that PAGE_BUSY is in PAGE_THP_HPTEFLAGS
> > is likely to be bad. If the page is busy, it's in the middle of
> > update so can't stably b
On Fri, 2013-05-03 at 11:01 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> > These kind of errors are pretty hard to find, its a pity to spend time
> > on them.
>
> Well, yes. From the first comment in gcc PR52080. "For the following
> testcase we gene
On Fri, 2013-05-03 at 21:54 +1000, David Gibson wrote:
> > _PAGE_BUSY is more like a read lock. It means it's being hashed, so what
> > is not stable is _PAGE_HASHPTE, slot index, _ACCESSED and _DIRTY. The
> > rest is stable and usually is what pmd_same looks at (though I have a
> > small doubt vs.
Hello Alexander,
On Fri, 3 May 2013 14:43:23 +0400
Alexander Popov wrote:
> Hello Anatolij,
>
> > Note that there is a patch for .device_prep_slave_sg() operation
> > for this driver as part of this series:
> > https://patchwork.kernel.org/patch/2368581/
> > https://patchwork.kernel.org/patch/2
On Fri, 2013-05-03 at 11:01 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> > These kind of errors are pretty hard to find, its a pity to spend time
> > on them.
>
> Well, yes. From the first comment in gcc PR52080. "For the following
> testcase we gene
> > Could ppc64 experts confirm using byte is safe, or should we really add
> > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > need a change...
...
> Also I'd be surprised if ppc64 is the only one with that problem... what
> about sparc64 and arm64 ?
Even x86 could be
On Fri, 2013-05-03 at 15:29 +0100, David Laight wrote:
> > > Could ppc64 experts confirm using byte is safe, or should we really add
> > > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > > need a change...
> ...
> > Also I'd be surprised if ppc64 is the only one with tha
> > > Also I'd be surprised if ppc64 is the only one with that problem... what
> > > about sparc64 and arm64 ?
> >
> > Even x86 could be affected.
> > The width of the memory cycles used by the 'bit set and bit clear'
> > instructions isn't documented. They are certainly allowed to do
> > RMW on ad
A change in the generic code highlighted that we were running with IRQs
(soft) enabled on Book3E 64-bit when trying to restart interrupts from
handle_exit(). This is a lesson to configure lockdep often :)
There is no reason to exit guest with soft_enabled == 1, a local_irq_enable()
call will do th
On 03.05.2013, at 18:11, Mihai Caraman wrote:
> A change in the generic code highlighted that we were running with IRQs
> (soft) enabled on Book3E 64-bit when trying to restart interrupts from
> handle_exit(). This is a lesson to configure lockdep often :)
>
> There is no reason to exit guest wi
On Thu, 2013-05-02 at 11:35 +1000, Benjamin Herrenschmidt wrote:
> Some ancient pHyp versions used to create a 8 bytes local-mac-address
> property in the device-tree instead of a 6 bytes one for veth.
>
> The Linux driver code to deal with that is an insane hack which also
> happens to break with
On 05/03/2013 11:11:10 AM, Mihai Caraman wrote:
A change in the generic code highlighted that we were running with
IRQs
(soft) enabled on Book3E 64-bit when trying to restart interrupts from
handle_exit(). This is a lesson to configure lockdep often :)
There is no reason to exit guest with sof
David Gibson writes:
> On Mon, Apr 29, 2013 at 01:21:49AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> We enable only if the we support 16MB page size.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>> arch/powerpc/include/asm/pgtable-ppc64.h | 3 +--
>> arch/powerpc/mm/pg
David Gibson writes:
> On Tue, Apr 30, 2013 at 09:12:09AM +0530, Aneesh Kumar K.V wrote:
>> David Gibson writes:
>>
>> > On Mon, Apr 29, 2013 at 01:07:22AM +0530, Aneesh Kumar K.V wrote:
>> >> From: "Aneesh Kumar K.V"
>> >>
>> >> On archs like powerpc that support different hugepage sizes, HP
David Gibson writes:
> On Fri, May 03, 2013 at 06:19:03PM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2013-05-03 at 14:52 +1000, David Gibson wrote:
>> > Here, specifically, the fact that PAGE_BUSY is in PAGE_THP_HPTEFLAGS
>> > is likely to be bad. If the page is busy, it's in the middle of
David Gibson writes:
> On Mon, Apr 29, 2013 at 01:21:45AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>
> What's the difference in meaning between pmd_huge() and pmd_large()?
>
#ifndef CONFIG_HUGETLB_PAGE
#define pmd_huge(x) 0
#endif
Also pmd_large do check for THP PTE flag,
David Gibson writes:
> On Mon, Apr 29, 2013 at 01:21:50AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> Hugepage invalidate involves invalidating multiple hpte entries.
>> Optimize the operation using H_BULK_REMOVE on lpar platforms.
>> On native, reduce the number of tlb flu
David Gibson writes:
> On Mon, Apr 29, 2013 at 01:21:51AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> With THP we set pmd to none, before we do pte_clear. Hence we can't
>> walk page table to get the pte lock ptr and verify whether it is locked.
>> THP do take pte lock befo
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, May 03, 2013 9:05 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs wa
On 05/03/2013 03:01:26 PM, Caraman Mihai Claudiu-B02008 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, May 03, 2013 9:05 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Caraman Mihai Claud
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, May 03, 2013 11:15 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; k...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and h
On Fri, 2013-05-03 at 17:30 +0100, Ben Hutchings wrote:
> > + /* Workaround for old/broken pHyp */
> > + if (mac_len == 8)
> > + mac_addr_p += 2;
> > + if (mac_len != 6) {
>
> Missing 'else' before the second if?
Absolutely... oops :-) I couldn't find a version of pHyp with the wr
The following patch implements a new PAPR change which allows
the OS to force the use of 32 bit MSIs, regardless of what
the PCI capabilities indicate. This is required for some
devices that advertise support for 64 bit MSIs but don't
actually support them.
Signed-off-by: Brian King
---
arch/p
On Sat, 2013-05-04 at 00:35 +0530, Aneesh Kumar K.V wrote:
>
> if the firmware doesn't support lockless TLBIE, we need to do locking
> at the guest side. pSeries_lpar_flush_hash_range does that.
We don't "need" to ... it's an optimization because by experience the FW
locking was horrible (and the
On Fri, 2013-05-03 at 18:24 +0200, Alexander Graf wrote:
> > There is no reason to exit guest with soft_enabled == 1, a
> > local_irq_enable()
> > call will do this for us so get rid of kvmppc_layz_ee() calls. With this fix
> > we eliminate irqs_disabled() warnings and some guest and host hangs re
On 05/03/2013 03:56:47 PM, Caraman Mihai Claudiu-B02008 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, May 03, 2013 11:15 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; k...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org
>
This v5 of the patch series is based on v4 sent by Lucas Kannebley Tavares
with a few changes:
1. Fix a compilation warning on the code from the first patch, where it was
missing a declaration of struct pci_host_bridge, used on the definition of
the function pointer pcibios_root_bridge_prepare()
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform
this detection and a hook to perform dynamic adding of the function only
for pseries. This is done by overwriting the weak
pcibios_root_bridge_prepare function
radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.
From: Lucas Kannebley Tavares
Signed-off-by: Kleber Sacilo
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, May 04, 2013 1:07 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; k...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] KVM: PPC: Book3E 64: Fix IRQs warnings and
On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:
> This patch series does:
> 1. max_bus_speed is used to set the device to gen2 speeds
> 2. on power there's no longer a conflict between the pseries call and other
> architectures, because the overwrite is done via a ppc_md ho
Now that we have AT_HWCAP2 support, start exposing some of the new
POWER8 features via it.
Signed-off-by: Nishanth Aravamudan
---
Note: there are, I think, some Freescale processors that also should be
updated to indicate they support ISEL, but I don't know which ones.
Since this is a new featur
On Fri, 2013-05-03 at 16:19 -0700, Nishanth Aravamudan wrote:
> +/* in AT_HWCAP2 */
> +#define PPC_FEATURE2_ARCH_2_07 0x8000
> +#define PPC_FEATURE2_HTM 0x4000
> +#define PPC_FEATURE2_DSCR 0x2000
> +#define PPC_FEATURE2_EBB 0x1000
> +
On 05/03/2013 05:59:32 PM, Caraman Mihai Claudiu-B02008 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, May 04, 2013 1:07 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; k...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org
>
On 04.05.2013 [09:23:51 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2013-05-03 at 16:19 -0700, Nishanth Aravamudan wrote:
> > +/* in AT_HWCAP2 */
> > +#define PPC_FEATURE2_ARCH_2_07 0x8000
> > +#define PPC_FEATURE2_HTM 0x4000
> > +#define PPC_FEATURE2_DSCR
kvmppc_lazy_ee_enable() was causing interrupts to be soft-enabled
(albeit hard-disabled) in kvmppc_restart_interrupt(). This led to
warnings, and possibly breakage if the interrupt state was later saved
and then restored (leading to interrupts being hard-and-soft enabled
when they should be at lea
On 05/03/2013 06:45:23 PM, Scott Wood wrote:
While we could just set PACA_IRQ_HARD_DIS after an exit to compensate,
instead hard-disable interrupts before entering the guest. This way,
we won't have to worry about interactions if we take an interrupt
during the guest entry code. While I don't s
Nishanth Aravamudan wrote:
> Now that we have AT_HWCAP2 support, start exposing some of the new
> POWER8 features via it.
>
> Signed-off-by: Nishanth Aravamudan
A few points:
We need a TAR bit as well, although this could be covered in 207?
For TM we need to turn it off if CONFIG_PPC_TRANSAC
Also, make HTM's presence dependent on the .config option.
Signed-off-by: Nishanth Aravamudan
---
Changes since v1:
- Add TAR.
- Make HTM config dependent.
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fcc54ad..26807e5 100644
--- a/arch/powe
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ae9f433..a792157 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -98,6 +98,7 @@ extern void __restore_cpu_e6500(void);
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a792157..b224cd5 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1999,6 +1999,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
Signed-off-by: Nishanth Aravamudan
---
Changes since v1:
- Add TAR.
- Use config dependent symbol for HTM.
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b224cd5..79cde71 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -10
According to the GCC sources, ISEL is enabled by default for the 8540,
8548, e500mc, e500mc64, e6500 processors.
From:
Nishanth Aravamudan
To:
b...@kernel.crashing.org,
Cc:
Steve Munroe/Rochester/IBM@IBMUS, Peter Bergner/Rochester/IBM@IBMUS,
Michael R Meissner/Cambridge/IBM@IBMUS, Michael Ne
Some ancient pHyp versions used to create a 8 bytes local-mac-address
property in the device-tree instead of a 6 bytes one for veth.
The Linux driver code to deal with that is an insane hack which also
happens to break with some choices of MAC addresses in qemu by testing
for a bit in the address
If OPAL returns an error, propagate it upward rather than spinning
seconds waiting for a CPU that will never show up
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/platforms/powernv/smp.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/po
On Sat, May 04, 2013 at 12:28:20AM +0530, Aneesh Kumar K.V wrote:
> David Gibson writes:
>
> > On Mon, Apr 29, 2013 at 01:21:45AM +0530, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V"
> >
> > What's the difference in meaning between pmd_huge() and pmd_large()?
> >
>
> #ifndef CONFIG_HUGE
51 matches
Mail list logo
