The Apple custom PIC only exist in some earlier machine models,
anything with an MPIC will crash on suspend if we register those
syscore ops unconditionally.
This is a regression caused by:
f5a592f7d74e38c5007876c731e6bf5580072e63
PM / PowerPC: Use struct syscore_ops instead of sysdevs for PM
The following series of patches enable KVM to exploit the hardware
hypervisor mode on 64-bit Power ISA Book3S machines. At present only
POWER7 is supported, but it would be easy to add other processors.
Running the KVM host in hypervisor mode means that the guest can use
both supervisor mode and
This moves the slb field, which represents the state of the emulated
SLB, from the kvmppc_vcpu_book3s struct to the kvm_vcpu_arch, and the
hpte_hash_[v]pte[_long] fields from kvm_vcpu_arch to kvmppc_vcpu_book3s.
This is in accord with the principle that the kvm_vcpu_arch struct
represents the
Rafał Miłecki zajec5-re5jqeeqqe8avxtiumw...@public.gmane.org writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+ return
From: David Gibson d...@au1.ibm.com
This improves I/O performance for guests using the PAPR
paravirtualization interface by making the H_PUT_TCE hcall faster, by
implementing it in real mode. H_PUT_TCE is used for updating virtual
IOMMU tables, and is used both for virtual I/O and for real I/O
There are several fields in struct kvmppc_book3s_shadow_vcpu that
temporarily store bits of host state while a guest is running,
rather than anything relating to the particular guest or vcpu.
This splits them out into a new kvmppc_host_state structure and
modifies the definitions in asm-offsets.c
Instead of branching out-of-line with the DO_KVM macro to check if we
are in a KVM guest at the time of an interrupt, this moves the KVM
check inline in the first-level interrupt handlers. This speeds up
the non-KVM case and makes sure that none of the interrupt handlers
are missing the check.
Instead of doing the kvm_guest_enter/exit() and local_irq_dis/enable()
calls in powerpc.c, this moves them down into the subarch-specific
book3s_pr.c and booke.c. This eliminates an extra local_irq_enable()
call in book3s_pr.c, and will be needed for when we do SMT4 guest
support in the book3s
In hypervisor mode, the LPCR controls several aspects of guest
partitions, including virtual partition memory mode, and also controls
whether the hypervisor decrementer interrupts are enabled. This sets
up LPCR at boot time so that guest partitions will use a virtual real
memory area (VRMA)
This arranges for the top-level arch/powerpc/kvm/powerpc.c file to
pass down some of the calls it gets to the lower-level subarchitecture
specific code. The lower-level implementations (in booke.c and book3s.c)
are no-ops. The coming book3s_hv.c will need this.
Signed-off-by: Paul Mackerras
This adds the infrastructure for handling PAPR hcalls in the kernel,
either early in the guest exit path while we are still in real mode,
or later once the MMU has been turned back on and we are in the full
kernel context. The advantage of handling hcalls in real mode if
possible is that we avoid
Doing so means that we don't have to save the flags anywhere and gets
rid of the last reference to to_book3s(vcpu) in arch/powerpc/kvm/book3s.c.
Doing so is OK because a program interrupt won't be generated at the
same time as any other synchronous interrupt. If a program interrupt
and an
This lifts the restriction that book3s_hv guests can only run one
hardware thread per core, and allows them to use up to 4 threads
per core on POWER7. The host still has to run single-threaded.
This capability is advertised to qemu through a new KVM_CAP_PPC_SMT
capability. The return value of
On 31.05.2011, at 08:40, Paul Mackerras wrote:
The following series of patches enable KVM to exploit the hardware
hypervisor mode on 64-bit Power ISA Book3S machines. At present only
POWER7 is supported, but it would be easy to add other processors.
Running the KVM host in hypervisor mode
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
Thinking about the testability of this a bit more ... how much
effort would it be to get this code running on a 970MP with SLOF?
There should only be a few POWER7 specific pieces, right?
Do you have a 970MP that has a usable
On 31.05.2011, at 14:35, Paul Mackerras wrote:
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
Thinking about the testability of this a bit more ... how much
effort would it be to get this code running on a 970MP with SLOF?
There should only be a few POWER7 specific pieces,
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
come with a patch to create platform devices (of_platform at that time),
for device_nodes which
Suzuki Poulose wrote:
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===
--- /dev/null
+++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
+ *
+ */
+blnxtins/* Find our address */
+nxtins:
On 05/31/2011 04:37 AM, Andreas Schwab wrote:
Rafał Miłeckizajec5-re5jqeeqqe8avxtiumw...@public.gmane.org writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct
Hi,
Apologies if this is the wrong forum for this message but I figured it was
a good place to start.
We have a new P4040 based board and are having lots of fun trying to get
our BDI3k to work with it. The BDI isn't able to get control/halt the
processor. I can go into more details if anybody
Larry Finger larry.fin...@lwfinger.net writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire
patrickdepinguin+linux...@gmail.com wrote:
Although I realize that what I need to achieve is unconventional, what
is the correct way of mapping a certain address range into memory, and
be able to execute from it?
Can you look at using
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
Larry Fingerlarry.fin...@lwfinger.net writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Mainly because the last two steps in the traceback are
Larry Finger larry.fin...@lwfinger.net writes:
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
Larry Fingerlarry.fin...@lwfinger.net writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Mainly because
Andreas Schwab sch...@linux-m68k.org writes:
Larry Finger larry.fin...@lwfinger.net writes:
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
Larry Fingerlarry.fin...@lwfinger.net writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not
On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote:
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
come with a patch to create
On Tue, May 31, 2011 at 7:17 AM, Dmitry Eremin-Solenikov
dbarysh...@gmail.com wrote:
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
come with
This patch set defines a binding for FSL MPIC message registers and implements
an API for accessing those message registers. Testing was done on a MPC8572DS
in an Linux-Linux AMP setup using OpenMCAPI (www.openmcapi.org) to communicate
between OS instances. The message register API is used by
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge meador_i...@mentor.com
Cc: Hollis Blanchard hollis_blanch...@mentor.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available message registers are initially discovered via nodes in the
On 05/26/2011 03:06 PM, Scott Wood wrote:
+- interrupts: Specifies a list of interrupt source and level-sense
pairs.
+ The type shall be prop-encoded-array. The length shall be equal
to
+ the number of bits set in the 'msg-receive-mask' property value.
Oh, just noticed
On Tue, 31 May 2011 14:19:02 -0500
Meador Inge meador_i...@mentor.com wrote:
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge meador_i...@mentor.com
Cc: Hollis Blanchard
On 5/31/11, Kumar Gala ga...@kernel.crashing.org wrote:
On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote:
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
On May 31, 2011, at 8:50 AM, Alexander Graf wrote:
On 31.05.2011, at 14:35, Paul Mackerras wrote:
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
Thinking about the testability of this a bit more ... how much
effort would it be to get this code running on a 970MP with
Sure, but that shouldn't happen with HDEC during the odd 50
instructions that it takes to enter the guest :)
It's more like 500 insns, including some ptesync, so lots of cycles
too.
I don't think its actually that bad.
There's a loop of 128 iterations of 3 insns.
I'm not saying it is
Hi,
trying to boot 3.0-rc1 on powerpc32 only progresses until:
Kernel virtual memory layout:
* 0xfffcf000..0xf000 : fixmap
And then the system hangs, does not respond to keyboard (sysrq does not
seem to work on this PowerBook G4). But after a while the system reboots
itself, so I
On Tue, 2011-05-31 at 16:50 -0700, Christian Kujau wrote:
Hi,
trying to boot 3.0-rc1 on powerpc32 only progresses until:
Kernel virtual memory layout:
* 0xfffcf000..0xf000 : fixmap
And then the system hangs, does not respond to keyboard (sysrq does not
seem to work on
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
Hrm, I had it working on a pair of powerbooks yesterday. Can you try
something like udbg-immortal on your kernel command line to see if
that makes a difference in the output ?
I'll try in a minute.
In the meantime, git bisect behaves
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
Hrm, I had it working on a pair of powerbooks yesterday. Can you try
something like udbg-immortal on your kernel command line to see if
that makes a difference in the output ?
Back in 2006 the udbg-immortal kernel option has been introduced:
commit 3b5e905ee3bd23e9311951890aba57a0dbc81ca4
Author: Benjamin Herrenschmidt b...@au1.ibm.com
Date: Wed Jun 7 12:06:20 2006 +1000
[PATCH] powerpc: Add udbg-immortal kernel option
...but I could not find it
(Cc'in Linus)
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
In the meantime, git bisect behaves kinda weird, I don't know what went
wrong here:
$ git bisect start
$ git bisect good # Linux 2.6.39
$ git bisect bad v3.0-rc1 # Linux 3.0-rc1
$ git bisect bad #
Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
Signed-off-by: Will Drewry w...@chromium.org
---
arch/powerpc/Kconfig |1 +
arch/powerpc/include/asm/seccomp.h |2 ++
2 files changed, 3
On Tue, 2011-05-31 at 20:02 -0700, Christian Kujau wrote:
(Cc'in Linus)
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
In the meantime, git bisect behaves kinda weird, I don't know what went
wrong here:
$ git bisect start
$ git bisect good # Linux 2.6.39
$ git
The interesting question of course is whether that 460SX stuff is the
same as what we're using internally :-)
[marri] Sometimes open-source and internal releases may not be the same
Because of open-source standards.
Can we fix that ?
[marri] Sure I will take a look at it.
Not sure how I would know -- But with my eiger kit, I got a
cd from amcc that had a patched 2.6.30 or something kernel
in it to support the 460SX. The pci code was basically
subverted by adding a port-link=1 at the very end of the
link check to always force it to succeed. However this code
On Tue, May 31, 2011 at 02:50:20PM +0200, Alexander Graf wrote:
On 31.05.2011, at 14:35, Paul Mackerras wrote:
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
Thinking about the testability of this a bit more ... how much
effort would it be to get this code running on
On Wed, Jun 01, 2011 at 12:34:43AM +0200, Segher Boessenkool wrote:
There's a loop of 128 iterations of 3 insns.
I'm not saying it is actually bad, just that that 50 is slightly off ;-)
That would be the TLB invalidation. On POWER7 we only need to do that
if the virtual cpu last ran on a
We have a TQM5200 board, which has GPIO lines hooked up to an SM501.
I've managed to come up with the following patch to the tqm5200 device
tree, which manages to convince the sm501 driver to attach an sm501-fb:
--- a/arch/powerpc/boot/dts/tqm5200.dts 2009-11-23 03:13:27.0 -0800
+++
On Tue, May 31, 2011 at 5:35 AM, Paul Mackerras pau...@samba.org wrote:
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
Thinking about the testability of this a bit more ... how much
effort would it be to get this code running on a 970MP with SLOF?
There should only be a few
49 matches
Mail list logo
