On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote:
> Oops... put the old linuxppc list on the CC, sorry!
>
> On Thu, Jun 24, 2010 at 23:45, Kyle Moffett wrote:
> > Hello,
> >
> > I've got a new P2020 (32bit mpc85xx family) board I'm working on a
> > port for that includes 2 NOR flashes (1
On Sun Jun 27 around 19:33:52 EST 2010 Alexander Graf wrote:
> Am 27.06.2010 um 10:14 schrieb Avi Kivity :
> > On 06/26/2010 02:25 AM, Alexander Graf wrote:
> > > +
> > > +PPC hypercalls
> > > +==
> > > +
> > > +The only viable ways to reliably get from guest context to host
> > > co
On 28.06.2010, at 09:18, Milton Miller wrote:
> On Sun Jun 27 around 19:33:52 EST 2010 Alexander Graf wrote:
>> Am 27.06.2010 um 10:14 schrieb Avi Kivity :
>>> On 06/26/2010 02:25 AM, Alexander Graf wrote:
>
+
+PPC hypercalls
+==
+
+The only viable ways to re
On 06/28/2010 10:49 AM, Alexander Graf wrote:
I don't believe we support the kernel actually doing a syscall to itself
anymore, at least on powerpc. The callers call the underlying system
call function, or kernel_thread.
That said, I would suggest we allocate a syscall number for this, as it
On 06/28/2010 09:33 AM, Alexander Graf wrote:
Could you do something similar in module_finalize() to patch loaded modules'
.text sections?
I could, but do we need it? I objdump -d | grep'ed all my modules and didn't
find any need to do so.
You mean even kvm.ko doesn't use privile
On 28.06.2010, at 10:13, Avi Kivity wrote:
> On 06/28/2010 10:49 AM, Alexander Graf wrote:
>>
>>> I don't believe we support the kernel actually doing a syscall to itself
>>> anymore, at least on powerpc. The callers call the underlying system
>>> call function, or kernel_thread.
>>>
>>> That
On 28.06.2010, at 10:15, Avi Kivity wrote:
> On 06/28/2010 09:33 AM, Alexander Graf wrote:
>>
>>> Could you do something similar in module_finalize() to patch loaded
>>> modules' .text sections?
>>>
>> I could, but do we need it? I objdump -d | grep'ed all my modules and didn't
>> find an
On 06/26/2010 02:16 AM, Alexander Graf wrote:
Currently the shadow paging code keeps an array of entries it knows about.
Whenever the guest invalidates an entry, we loop through that entry,
trying to invalidate matching parts.
While this is a really simple implementation, it is probably the most
On 06/28/2010 11:21 AM, Alexander Graf wrote:
The other alternative I'd see is to reuse an instruction that is not sc. We could for
example pull the mfpvr trick again, but pass a different magic value in the register this
time that tells the hypervisor "this is a hypercall".
Or we could reser
On 06/28/2010 11:23 AM, Alexander Graf wrote:
You mean even kvm.ko doesn't use privileged instructions?
It does, but I don't think it's worth speeding those up. There are only a
couple. Most of the privileged instructions in PPC KVM are statically compiled
into the kernel because we need
On 28.06.2010, at 10:28, Avi Kivity wrote:
> On 06/26/2010 02:16 AM, Alexander Graf wrote:
>> Currently the shadow paging code keeps an array of entries it knows about.
>> Whenever the guest invalidates an entry, we loop through that entry,
>> trying to invalidate matching parts.
>>
>> While thi
On 06/28/2010 11:55 AM, Alexander Graf wrote:
+
+static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
+ return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
+ return hash_64(vpage& 0xfULL, HPTEG_HASH_BITS_VPTE);
+
Am 28.06.2010 um 11:12 schrieb Avi Kivity :
On 06/28/2010 11:55 AM, Alexander Graf wrote:
+
+static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
+return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
+return hash_64(vpage&
On 06/28/2010 12:27 PM, Alexander Graf wrote:
Am I looking at old code?
Apparently. Check book3s_mmu_*.c
I don't have that pattern.
(another difference is using struct hlist_head instead of list_head,
which I recommend since it saves space)
Hrm. I thought about this quite a bit befor
Avi Kivity wrote:
> On 06/28/2010 12:27 PM, Alexander Graf wrote:
>>> Am I looking at old code?
>>
>>
>> Apparently. Check book3s_mmu_*.c
>
> I don't have that pattern.
It's in this patch.
> +static void invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
> +{
> + dprintk_mmu("KVM:
On 06/28/2010 12:55 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 06/28/2010 12:27 PM, Alexander Graf wrote:
Am I looking at old code?
Apparently. Check book3s_mmu_*.c
I don't have that pattern.
It's in this patch.
Yes. Silly me.
+static void inva
Avi Kivity wrote:
> On 06/28/2010 12:55 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/28/2010 12:27 PM, Alexander Graf wrote:
>>>
> Am I looking at old code?
>
Apparently. Check book3s_mmu_*.c
>>> I don't have that pattern.
>>>
>>
On 06/28/2010 04:25 PM, Alexander Graf wrote:
Less and simpler code, better reporting through slabtop, less wastage
of partially allocated slab pages.
But it also means that one VM can spill the global slab cache and kill
another VM's mm performance, no?
What do you mean b
Avi Kivity wrote:
> On 06/28/2010 04:25 PM, Alexander Graf wrote:
>>>
> Less and simpler code, better reporting through slabtop, less wastage
> of partially allocated slab pages.
>
>
But it also means that one VM can spill the global slab cache and kill
another V
On Wed, Jun 09, 2010 at 06:08:54PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I get the following during boot on a 16 CPU Power box. Thoughts?
> >
On Mon, Jun 28, 2010 at 03:18, Milton Miller wrote:
> On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote:
>> I've got a new P2020 (32bit mpc85xx family) board I'm working on a
>> port for that includes 2 NOR flashes (128MB each) and a removable
>> SO-RDIMM of 2GB or 4GB. Unfortunately when
> I think there may be something weird going on with the memcpy
> in my build. If I use the following patch I no longer get
> errors when I mount the filesystem. All I did was replace
> the memcpy with a loop.
>
> I'm not sure what's special about this particular use of
> memcpy. I can't be
On Mon, 2010-06-28 at 09:49 -0700, Paul E. McKenney wrote:
> And it does appear to be reproducible perhaps 50% of boots running
> CONFIG_PREEMPT on kernel-ml8. I have not yet seen it on any other
> system.
> Do you have a patch to instrument the interrupts so as to get the info
> you need, or shou
Dear "Steve Deiters",
In message <181804936abc2349be503168465576460f20d...@exchserver.basler.com> you
wrote:
> > I think there may be something weird going on with the memcpy
> > in my build. If I use the following patch I no longer get
> > errors when I mount the filesystem. All I did was re
Excerpts from Jason Baron's message of Thu Jun 24 04:03:54 +1000 2010:
> overall this patch is a major improvement! My question though is
> about the naming of the compat syscalls in the context of events. I
> believe this patch differeniates compat syscall event names as:
> "sys32_enter_sname", an
Excerpts from Steven Rostedt's message of Thu Jun 24 01:02:19 +1000 2010:
> > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> > index 34e3580..82246ce 100644
> > --- a/kernel/trace/trace_syscalls.c
> > +++ b/kernel/trace/trace_syscalls.c
> > @@ -431,6 +431,14 @@ void un
Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah
> Signed-off-by: Mark Miesfeld
> Signed-off-by: Prodyut Hazarika
>
--SNIP--
> + dev_err(ap->dev
No logic changes, only spelling.
Signed-off-by: Michael Neuling
---
arch/powerpc/kernel/process.c |2 +-
include/linux/topology.h |2 +-
kernel/sched_fair.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-tip/arch/powerpc/kernel/process.c
Hi Stephen,
On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer
wrote:
>
> 2) config OF is currently implemented in the architecture code. This
> should be non-architecture dependent and selected by the arches that
> need it.
>
> Comments greatly appreciated, in particular if you have
> li
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell
---
arch/microblaze/Kconfig |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 76818f9..
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell
---
arch/powerpc/Kconfig |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..3697231 1
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell
---
arch/sparc/Kconfig |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6f1470b..d02e8ac 100644
--
Signed-off-by: Stephen Rothwell
---
drivers/of/Kconfig |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 7cecc8f..1678dbc 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,3 +1,6 @@
+config OF
+ bool
+
con
now that CONFIG_OF is defined globally
Signed-off-by: Stephen Rothwell
---
arch/microblaze/Kconfig |3 ---
arch/powerpc/Kconfig|3 ---
arch/sparc/Kconfig |3 ---
3 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
From: Stephen Rothwell
Date: Tue, 29 Jun 2010 12:44:50 +1000
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell
Acked-by: David S. Miller
___
Linuxppc-dev mailing lis
On Mon, Jun 28, 2010 at 7:38 PM, Stephen Rothwell wrote:
> Hi Stephen,
>
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer
> wrote:
>>
>> 2) config OF is currently implemented in the architecture code. This
>> should be non-architecture dependent and selected by the arches that
>> need
Hi Grant,
On Mon, 28 Jun 2010 22:56:14 -0700 Grant Likely
wrote:
>
> I've got an Ack from David now. I'll wait for more acks, and then
> pull the whole series of 5 into my devicetree-next branch. It's
> certainly less invasive that some of the other changes arch changes
> I've taken through my
37 matches
Mail list logo
