On Thu, 2013-05-09 at 22:09 -0500, Scott Wood wrote:
> lockdep.c has this:
> /*
> * So we're supposed to get called after you mask local IRQs,
> * but for some reason the hardware doesn't quite think you did
> * a proper job.
> */
> if (DEBUG_LOCKS_
On 05/10/2013 04:51 PM, David Gibson wrote:
> On Mon, May 06, 2013 at 05:25:53PM +1000, Alexey Kardashevskiy wrote:
>> This adds real mode handlers for the H_PUT_TCE_INDIRECT and
>> H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio
>> devices or emulated PCI. These calls allow adding
Currently we only set the "to" address in the branch stack when the CPU
explicitly gives us a value. Unfortunately it only does this for XL form
branches (eg blr, bctr, bctar) and not I and B form branches (eg b, bc).
Fortunately if we read the instruction from memory we can extract the offset of
On Thu, May 09, 2013 at 08:39:15AM +1000, Michael Neuling wrote:
> > Just because I'm curious.. however does that happen? Surely the CPU
> > knows where next to fetch instructions?
>
> For computed gotos (ie. branch to a register value), the hardware gives
> you the from and to address in the bran
On Fri, May 10, 2013 at 8:43 PM, Peter Zijlstra wrote:
> On Thu, May 09, 2013 at 08:39:15AM +1000, Michael Neuling wrote:
>> > Just because I'm curious.. however does that happen? Surely the CPU
>> > knows where next to fetch instructions?
>>
>> For computed gotos (ie. branch to a register value),
On Fri, 2013-05-10 at 20:50 +1000, Michael Neuling wrote:
> The buffer is in the core (not main memory) and hence only has limited
> entries. So skipping entries that can hopefully be determined in
> other ways means we can log more branches.
>
> That being said, it's a PITA for the kernel ;-)
I
On Thu, 2013-03-28 at 21:28 -0700, Brian Norris wrote:
> On Wed, Mar 27, 2013 at 5:25 AM, Roy Zang wrote:
> > memory is allocated by devm_kzalloc, so release it using
> > devm_kfree() instead kfree();
>
> You are correct that it should not be freed with kfree(). But the
> correct solution is that
On Fri, May 10, 2013 at 08:07:00AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-09 at 16:27 -0500, Scott Wood wrote:
> > On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
> > > On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> > > >
> > > > Actually in the case GS=1 even if E
On 09.05.2013, at 14:36, Caraman Mihai Claudiu-B02008 wrote:
>> -Original Message-
>> From: tiejun.chen [mailto:tiejun.c...@windriver.com]
>> Sent: Thursday, May 09, 2013 2:40 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ag...@suse.de; kv
On 07.05.2013, at 12:23, Tiejun Chen wrote:
> CONFIG_PPC_DOORBELL is enough to cover all variants.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/kvm/booke.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> in
On 05/10/2013 01:14:27 PM, Alexander Graf wrote:
On 07.05.2013, at 12:23, Tiejun Chen wrote:
> CONFIG_PPC_DOORBELL is enough to cover all variants.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/kvm/booke.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/po
On 10.05.2013, at 20:17, Scott Wood wrote:
> On 05/10/2013 01:14:27 PM, Alexander Graf wrote:
>> On 07.05.2013, at 12:23, Tiejun Chen wrote:
>> > CONFIG_PPC_DOORBELL is enough to cover all variants.
>> >
>> > Signed-off-by: Tiejun Chen
>> > ---
>> > arch/powerpc/kvm/booke.c |2 +-
>> > 1 file
On 05/10/2013 12:57:33 PM, Alexander Graf wrote:
Could you guys please collect performance data during the next weeks
on both guest-directed ISIs as well as VF MMIOs (preferably with
in-kernel MMIO), so that we can decide on the direction that's worth
going towards?
Collecting data on VF M
Am 10.05.2013 um 21:22 schrieb Scott Wood :
> On 05/10/2013 12:57:33 PM, Alexander Graf wrote:
>> Could you guys please collect performance data during the next weeks on both
>> guest-directed ISIs as well as VF MMIOs (preferably with in-kernel MMIO), so
>> that we can decide on the direction
From: David Woodhouse
Some versions of GCC apparently expect this to be provided by libgcc.
Signed-off-by: David Woodhouse
---
Untested.
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 19e096b..f077dc2 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/power
On Fri, 2013-05-10 at 22:12 +0800, Kevin Hao wrote:
> So I would assume you will not pick up these two patches, right?
> http://patchwork.ozlabs.org/patch/235530/
> http://patchwork.ozlabs.org/patch/235532/
>
> Anyway it is more easier to enable the external proxy by using this method.
> But if yo
On Sat, 2013-05-11 at 07:49 +1000, Benjamin Herrenschmidt wrote:
> I would keep the EE_EDGE bit definition. I have no objection to a gradual
> approach however for the other one where we apply it as is now to enable
> coreint while you do a rework to make it better :-)
Note also that I generally d
On 05/10/2013 12:01:19 AM, Bhushan Bharat-R65777 wrote:
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Scott Wood
> Sent: Friday, May 10, 2013 8:40 AM
> To: Alexander Graf; Benjamin Herrenschmidt
> Cc: kvm-...@vger.ker
On 05/09/2013 11:40:08 PM, tiejun.chen wrote:
On 05/10/2013 11:34 AM, Bhushan Bharat-R65777 wrote:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 705fc5c..eb89b83 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -673,7 +673,7 @@ int kvmppc_vcpu_run(
On 05/10/2013 12:01:38 AM, Bhushan Bharat-R65777 wrote:
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Scott Wood
> Sent: Friday, May 10, 2013 8:40 AM
> To: Alexander Graf; Benjamin Herrenschmidt
> Cc: kvm-...@vger.ker
20 matches
Mail list logo
