From: Sam Ravnborg
Date: Wed, 18 Aug 2010 07:39:55 +0200
>> @@ -15,7 +15,7 @@ lib-$(CONFIG_SPARC32) += divdi3.o udivdi3.o
>> lib-$(CONFIG_SPARC32) += copy_user.o locks.o
>> lib-y += atomic_$(BITS).o
>> lib-$(CONFIG_SPARC32) += lshrdi3.o ashldi3.o
>> -lib-y += rw
> diff --git a/arch/sparc/lib/Makefile b/arch/sparc/lib/Makefile
> index c4b5e03..fa4c3ea 100644
> --- a/arch/sparc/lib/Makefile
> +++ b/arch/sparc/lib/Makefile
> @@ -15,7 +15,7 @@ lib-$(CONFIG_SPARC32) += divdi3.o udivdi3.o
> lib-$(CONFIG_SPARC32) += copy_user.o locks.o
> lib-y +
From: Benjamin Herrenschmidt
Date: Wed, 18 Aug 2010 15:03:23 +1000
> I tried various tricks but so far they didn't work. I'll have another
> look tomorrow, but I may end up having to keep all the crap typecasts.
The casts are pretty much unavoidable.
Here's what I'm going to end up using on spa
On Wed, 2010-08-18 at 14:38 +1000, Benjamin Herrenschmidt wrote:
>
> Here's an untested patch for the folks on linuxppc-dev to look at,
> I'll
> review my own stuff & test tomorrow.
Allright, gcc's being a pain, and atomics are a struct so we can't that
easily assign.
I tried various tricks but
On Tue, 2010-08-17 at 19:14 -0700, David Miller wrote:
> > I merged your pull request, but you've got some fixing up to do,
> > methinks. I also really think you need to make your rwsem's use 64-bit
> > values on sparc64, because otherwise you can overflow the mmap_sem by
> > having more than 6553
On Tue, 2010-08-17 at 13:36 +0200, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Richard Cochran wrote:
> > On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote:
> > > Another difference is that we generally use ioctl for devices that can
> > > be enumerated, while syscalls are for sys
On Tue, 2010-08-17 at 10:53 +0200, Richard Cochran wrote:
> On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote:
> > 3) I'm not sure I see the benefit of being able to have multiple
> > frequency corrected time domains. In other words, what benefit would
> > you get from adjusting a PTP cl
On Tue, Aug 17, 2010 at 03:05:05PM -0700, Tirumala Marri wrote:
> I am seeing weird issue with latest kernel. “make uImage” failes with “no
> rule to make target” error message.
>
> Has anything changed recently ?
>
>
>
> ---msg
>
> {tma...@svdclab61}> make 44x/canyonlands_de
I am seeing weird issue with latest kernel. “make uImage” failes with “no
rule to make target” error message.
Has anything changed recently ?
---msg
{tma...@svdclab61}> make 44x/canyonlands_defconfig
#
# configuration written to .config
#
{tma...@svdclab61}> make uImage
On 17.08.2010, at 20:28, Scott Wood wrote:
> On Tue, 17 Aug 2010 15:57:56 +0200
> Alexander Graf wrote:
>
>> There are some heuristics in the PPC power management code that try to find
>> out if the particular hardware we're running on supports proper power
>> management
>> or just hangs the m
On Tue, 17 Aug 2010 15:57:56 +0200
Alexander Graf wrote:
> There are some heuristics in the PPC power management code that try to find
> out if the particular hardware we're running on supports proper power
> management
> or just hangs the machine when going into nap mode.
>
> Since we know tha
Micha Nelissen wrote:
> Can you explain what the difference what you mean with relied on
> proprietary vs standard? E.g. setting the port-write destination ID
> register is standardized? And the format of the port-write message
> itself is also.
The original description should use "error-stopped
Micha Nelissen wrote:
>
> I agree it's desirable to have this information. Notes:
> 1) is rio_dev->prev used anywhere? (maybe I missed it)
It is used to scan route back when servicing an orphaned PW message.
I also see its future use when invalidating route(s) in case of device
removal.
> 2) i
Micha Nelissen wrote:
>
> It's not problematic, but personally I find function calls that pass 0
> or 1 as an argument hard to read. Likewise for boolean parameters. An
> alternative would be to have defines SW_SYSFS_CREATE etc. It's a minor
item.
>
I will add defines.
___
Micha Nelissen wrote:
>
> Primarily due to the single entry queue, the order of checking is
> probably insignificant? :-)
Help sometimes only but gives a feeling that I did all that is possible
;)
> Anyway, I don't mind changing the order.
>
> Micha
From: Hollis Blanchard
Missing local variable.
Signed-off-by: Hollis Blanchard
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/44x_tlb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
index 9f71b8d..5f3cff8 1
From: Hollis Blanchard
Developers can now tell at a glace the exact type of the premature interrupt,
instead of just knowing that there was some premature interrupt.
Signed-off-by: Hollis Blanchard
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |8 ++--
1 files changed, 6
From: Hollis Blanchard
Match only the first part of cur_cpu_spec->platform.
440GP (the first 440 processor) is identified by the string "ppc440gp", while
all later 440 processors use simply "ppc440".
Signed-off-by: Hollis Blanchard
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/44x.c |
Now that the actual mtsr doesn't do anything anymore, we can move the sr
contents over to the shared page, so a guest can directly read and write
its sr contents from guest context.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h |1 -
arch/powerpc/include/asm/kvm_par
After a flush the sid map contained lots of entries with 0 for their gvsid and
hvsid value. Unfortunately, 0 can be a real value the guest searches for when
looking up a vsid so it would incorrectly find the host's 0 hvsid mapping which
doesn't belong to our sid space.
So let's also check for the
There are some heuristics in the PPC power management code that try to find
out if the particular hardware we're running on supports proper power management
or just hangs the machine when going into nap mode.
Since we know that KVM is safe with nap, let's force enable it in the PV code
once we're
Right now we're examining the contents of Book3s_32's segment registers when
the register is written and put the interpreted contents into a struct.
There are two reasons this is bad. For starters, the struct has worse real-time
performance, as it occupies more ram. But the more important part is
This is the guest side of the mtsr acceleration. Using this a guest can now
call mtsrin with almost no overhead as long as it ensures that it only uses
it with (MSR_IR|MSR_DR) == 0. Linux does that, so we're good.
Signed-off-by: Alexander Graf
---
arch/powerpc/kernel/asm-offsets.c |1 +
arch
It turns out the in-kernel hash function is sub-optimal for our subtle
hash inputs where every bit is significant. So let's revert to the original
hash functions.
This reverts commit 05340ab4f9a6626f7a2e8f9fe5397c61d494f445.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_32_mmu_host.
This patch moves debugging printks for shadow SLB debugging over to tracepoints.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 22 ++
arch/powerpc/kvm/trace.h | 73 +
2 files changed, 78 insertions(+), 17 deleti
The current approach duplicates the spr->bat finding logic and makes it harder
to reuse the actually used variables. So let's move everything down to the spr
handler.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_emulate.c | 48
1 files changed,
On Book3S a mtmsr with the MSR_POW bit set indicates that the OS is in
idle and only needs to be waked up on the next interrupt.
Now, unfortunately we let that bit slip into the stored MSR value which
is not what the real CPU does, so that we ended up executing code like
this:
r = mfmsr()
There is a race condition in the pte invalidation code path where we can't
be sure if a pte was invalidated already. So let's move the spin lock around
to get rid of the race.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_mmu_hpte.c | 14 --
1 files changed, 8 insertion
So far we've been restricting ourselves to r0-r29 as registers an mtmsr
instruction could use. This was bad, as there are some code paths in
Linux actually using r30.
So let's instead handle all registers gracefully and get rid of that
stupid limitation
Signed-off-by: Alexander Graf
---
arch/po
This patch moves Book3s MMU debugging over to tracepoints.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 13 +--
arch/powerpc/kvm/trace.h | 34 +
2 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/
Up until now we were doing segment mappings wrong on Book3s_32. For Book3s_64
we were using a trick where we know that a single mmu_context gives us 16 bits
of context ids.
The mm system on Book3s_32 instead uses a clever algorithm to distribute VSIDs
across the available range, so a context id re
This patch moves the SPTE flush debug printk over to tracepoints.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_mmu_hpte.c |3 +--
arch/powerpc/kvm/trace.h | 29 +
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc
We had an arbitrary limitation in mtmsrd L=1 that kept us from using r30 and
r31 as input registers. Let's get rid of that and get more potential speedups!
Signed-off-by: Alexander Graf
---
arch/powerpc/kernel/kvm.c | 21 +
arch/powerpc/kernel/kvm_emul.S |8 +++
When hitting a no-execute or read-only data/inst storage interrupt we were
flushing the respective PTE so we're sure it gets properly overwritten next.
According to the spec, this is unnecessary though. The guest issues a tlbie
anyways, so we're safe to just keep the PTE around and have it manuall
When the guest jumps into kernel mode and has the magic page mapped, theres a
very high chance that it will also use it. So let's detect that scenario and
map the segment accordingly.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s.c | 10 ++
1 files changed, 10 insertions(+)
We will soon add SR PV support to the shared page, so we need some
infrastructure that allows the guest to query for features KVM exports.
This patch adds a second return value to the magic mapping that
indicated to the guest which features are available.
Signed-off-by: Alexander Graf
---
arch/
When having a decrementor interrupt pending, the dequeuing happens manually
through an mtdec instruction. This instruction simply calls dequeue on that
interrupt, so the int_pending hint doesn't get updated.
This patch enables updating the int_pending hint also on dequeue, thus
correctly enabling
The different ways of flusing shadow ptes have their own debug prints which use
stupid old printk.
Let's move them to tracepoints, making them easier available, faster and
possible to activate on demand
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_mmu_hpte.c | 18 +++-
We have a debug printk on every exit that is usually #ifdef'ed out. Using
tracepoints makes a lot more sense here though, as they can be dynamically
enabled.
This patch converts the most commonly used debug printks of EXIT_DEBUG to
tracepoints.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm
Howdy,
This is my local patch queue with stuff that has accumulated over the last
weeks on KVM for PPC with some last minute fixes, speedups and debugging help
that I needed for the KVM Forum ;-).
The highlights of this set are:
- Converted most important debug points to tracepoints
- Flush
The define VSID_ALL is unused. Let's remove it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_64_mmu_host.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index e7c4d00..4040c8d 1
This patch moves the generic mmu map debugging over to tracepoints.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_mmu_hpte.c |3 +++
arch/powerpc/kvm/trace.h | 29 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/power
Micha Nelissen wrote:
>
> Perhaps an idea is to use the repeated port-write sending feature so
> that dropped port-writes are not a problem anymore.
>
Unfortunately, this feature is not defined by RIO spec. This is
proprietary function, so we
cannot rely on it. Yes, this is nice feature of Tsi57
On Tuesday 17 August 2010, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote:
> > Another difference is that we generally use ioctl for devices that can
> > be enumerated, while syscalls are for system services that are not tied to
> > a specific device. This ar
On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote:
> Another difference is that we generally use ioctl for devices that can
> be enumerated, while syscalls are for system services that are not tied to
> a specific device. This argument works both ways for PTP IMHO: On the one
> hand you
On Tuesday 17 August 2010, Richard Cochran wrote:
> > Why did you not want to add syscalls? Adding ioctls instead of syscalls
> > does not make the interface better, just less visible.
>
> I bet that, had I posted patch set with new syscalls, someone would
> have said, "You are adding new syscalls
On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote:
> 3) I'm not sure I see the benefit of being able to have multiple
> frequency corrected time domains. In other words, what benefit would
> you get from adjusting a PTP clock's frequency instead of just
> adjusting the system's time freq
On Mon, Aug 16, 2010 at 09:59:39PM +0200, Arnd Bergmann wrote:
> Why does it matter how long it takes to read the clock? I wasn't thinking
> of replacing the system clock with this, just exposing the additional
> clock as a new clockid_t value that can be accessed using the existing
> syscalls.
Ok
Bounine, Alexandre wrote:
Micha Nelissen wrote:
This is not 'Gen2' specific, as these error management extensions also
exist in v1.2/1.3 (?) of the specification? E.g. tsi56x and tsi57x
could
support this functionality?
Correct. EM extensions exist since v1.3. But implementation before Gen2
Bounine, Alexandre wrote:
That "real" PW message may be dropped by the controller (85xx is good
example). Everything depends on number of PW messages directed to the
host/controller. I am trying to use the first available notification to
service device removal. If the "real" PW message is receive
Bounine, Alexandre wrote:
Why not make a sw_sysfs_create and sw_sysfs_remove? Is better for
readability. Now you call 'sw_sysfs(dev, 0)' or 'sw_sysfs(dev, 1)';
I just do not want to have an extra member here. Not every switch will
require own sysfs attributes, but every switch will be presented
Bounine, Alexandre wrote:
capable to receive and keep only one PW message. Therefore, I copy it
into the driver's FIFO and re-enable HW Rx queue (it is called queue but
can accept only one entry) ASAP. I have a test setup that is capable
generate multiple PW messages and see many messages discard
Bounine, Alexandre wrote:
As RapidIO is a switched network, the concept of 'previous' and 'next'
devices is invalid. Perhaps it's just the way they were
discovered/enumerated, but that does not matter any more at runtime.
Or at least, should not matter.
Yes, the "previous" and "next" have to b
53 matches
Mail list logo
