On Tue, May 07, 2013 at 04:27:49PM +1000, Alexey Kardashevskiy wrote:
> On 05/07/2013 04:02 PM, David Gibson wrote:
> > On Tue, May 07, 2013 at 03:51:31PM +1000, Alexey Kardashevskiy wrote:
> >> On 05/07/2013 03:29 PM, David Gibson wrote:
> >>> On Mon, May 06, 2013 at 05:25:56PM +1000, Alexey Karda
On 05/07/2013 04:02 PM, David Gibson wrote:
> On Tue, May 07, 2013 at 03:51:31PM +1000, Alexey Kardashevskiy wrote:
>> On 05/07/2013 03:29 PM, David Gibson wrote:
>>> On Mon, May 06, 2013 at 05:25:56PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TC
On Tue, May 07, 2013 at 03:51:31PM +1000, Alexey Kardashevskiy wrote:
> On 05/07/2013 03:29 PM, David Gibson wrote:
> > On Mon, May 06, 2013 at 05:25:56PM +1000, Alexey Kardashevskiy wrote:
> >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >> and H_STUFF_TCE requests withou
On 05/07/2013 03:29 PM, David Gibson wrote:
> On Mon, May 06, 2013 at 05:25:56PM +1000, Alexey Kardashevskiy wrote:
>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>> and H_STUFF_TCE requests without passing them to QEMU, which should
>> save time on switching to QEMU and bac
On Mon, May 06, 2013 at 05:25:56PM +1000, Alexey Kardashevskiy wrote:
> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> and H_STUFF_TCE requests without passing them to QEMU, which should
> save time on switching to QEMU and back.
>
> Both real and virtual modes are supported
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 multiple entries
> (up to 512) into the TCE tabl
On Tue, May 07, 2013 at 07:34:30AM +1000, Benjamin Herrenschmidt wrote:
>On Mon, 2013-05-06 at 21:44 +0800, Gavin Shan wrote:
>> We needn't configure IO windows for the corresponding PEs on PHB3
>> since that doesn't support IO.
>
>Here too, no need for such a flag, just check that
>pci_controller-
On Tue, May 07, 2013 at 07:33:02AM +1000, Benjamin Herrenschmidt wrote:
>On Mon, 2013-05-06 at 21:44 +0800, Gavin Shan wrote:
>> The patch intends to set the special flag (PCI_BUS_FLAGS_NO_IO) for
>> root buses so PCI core will skip assignment for IO stuff. Besides,
>> we also clear the IO resource
We are getting build errors with CONFIG_PROC_FS=n:
arch/powerpc/kernel/rtas_flash.c
In function 'rtas_flash_init':
745:33: error: unused variable 'f' [-Werror=unused-variable]
But rtas_flash.c should not be built when CONFIG_PROC_FS=n, beacause all
it does is provide a /proc interface to the
On Mon, May 06, 2013 at 09:06:15PM -0700, Greg KH wrote:
> On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote:
> > From: Vaidyanathan Srinivasan
> >
> > Commit 7122b7bc1757682049780179d7c216dd1c83 upstream.
> >
> > The following commit breaks numa distance setup for old powerpc
On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote:
> From: Vaidyanathan Srinivasan
>
> Commit 7122b7bc1757682049780179d7c216dd1c83 upstream.
>
> The following commit breaks numa distance setup for old powerpc
> systems that use form0 encoding in device tree.
>
> commit 41eab6
On Mon, 2013-05-06 at 22:05 -0500, Scott Wood wrote:
> On 05/06/2013 07:03:14 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-05-06 at 18:53 -0500, Scott Wood wrote:
> > >
> > > > Ie. The last stage of entry will hard enable, so they should be
> > > > soft-enabled too... if not, latency trackers
From: Vaidyanathan Srinivasan
Commit 7122b7bc1757682049780179d7c216dd1c83 upstream.
The following commit breaks numa distance setup for old powerpc
systems that use form0 encoding in device tree.
commit 41eab6f88f24124df89e38067b3766b7bef06ddb
powerpc/numa: Use form 1 affinity to setup node
On 05/07/2013 11:42 AM, Alex Williamson wrote:
> On Tue, 2013-05-07 at 10:49 +1000, Alexey Kardashevskiy wrote:
>> On 05/07/2013 07:07 AM, Alex Williamson wrote:
>>> On Mon, 2013-05-06 at 17:21 +1000, a...@ozlabs.ru wrote:
From: Alexey Kardashevskiy
The IOMMU API implements groups c
On 05/06/2013 07:03:14 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-05-06 at 18:53 -0500, Scott Wood wrote:
>
> > Ie. The last stage of entry will hard enable, so they should be
> > soft-enabled too... if not, latency trackers will consider the
whole
> > guest periods as "interrupt disabled"
On 05/06/2013 09:43:37 PM, tiejun.chen wrote:
On 05/07/2013 10:06 AM, Scott Wood wrote:
On 05/06/2013 08:56:25 PM, tiejun.chen wrote:
On 05/07/2013 07:50 AM, Scott Wood wrote:
On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
On 05/06/2013 11:10 AM, Tiejun Chen wrote:
For the external interrupt,
On 05/07/2013 10:06 AM, Scott Wood wrote:
On 05/06/2013 08:56:25 PM, tiejun.chen wrote:
On 05/07/2013 07:50 AM, Scott Wood wrote:
On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
On 05/06/2013 11:10 AM, Tiejun Chen wrote:
For the external interrupt, the decrementer exception and the doorbell
exc
Saw this warning again, and this time from the ret_from_fork path.
It seems we could clear the back chain earlier in copy_thread(), which
could cover both path, and also fix potential lockdep usage in
schedule_tail(), or exception occurred before we clear the back chain.
Signed-off-by: Li Zhong
On 05/06/2013 08:56:25 PM, tiejun.chen wrote:
On 05/07/2013 07:50 AM, Scott Wood wrote:
On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
On 05/06/2013 11:10 AM, Tiejun Chen wrote:
For the external interrupt, the decrementer exception and the
doorbell
excpetion, we also need to soft-disable inter
On 05/07/2013 07:50 AM, Scott Wood wrote:
On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
On 05/06/2013 11:10 AM, Tiejun Chen wrote:
For the external interrupt, the decrementer exception and the doorbell
excpetion, we also need to soft-disable interrupts while doing as host
interrupt handlers sin
On Tue, 2013-05-07 at 10:49 +1000, Alexey Kardashevskiy wrote:
> On 05/07/2013 07:07 AM, Alex Williamson wrote:
> > On Mon, 2013-05-06 at 17:21 +1000, a...@ozlabs.ru wrote:
> >> From: Alexey Kardashevskiy
> >>
> >> The IOMMU API implements groups creating/deletion, device binding
> >> and IOMMU ma
Peter & Stephane,
We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
struct perf_branch_entry.
Sometimes on POWER8 we may not be able to fill out the "to" address. We
initially thought of just making this 0, but it's feasible that this
could be a valid address to branch to.
T
On 05/06/2013 10:58 PM, Alexander Graf wrote:
On 05/06/2013 04:53 AM, Tiejun Chen wrote:
Actually E500MC also support doorbell exception, and CONFIG_PPC_E500MC
can cover BOOK3E/BOOK3E_64 as well.
Signed-off-by: Tiejun Chen
---
arch/powerpc/kvm/booke.c |2 +-
1 file changed, 1 insertion(+
On 05/07/2013 07:07 AM, Alex Williamson wrote:
> On Mon, 2013-05-06 at 17:21 +1000, a...@ozlabs.ru wrote:
>> From: Alexey Kardashevskiy
>>
>> The IOMMU API implements groups creating/deletion, device binding
>> and IOMMU map/unmap operations.
>>
>> The PowerPC implementation uses most of the API e
On Mon, 2013-05-06 at 18:53 -0500, Scott Wood wrote:
>
> > Ie. The last stage of entry will hard enable, so they should be
> > soft-enabled too... if not, latency trackers will consider the whole
> > guest periods as "interrupt disabled"...
>
> OK... I guess we already have that problem on 32-bit
On 05/05/2013 04:03:08 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-05-03 at 18:45 -0500, Scott Wood wrote:
> 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
On 05/05/2013 10:13:17 PM, tiejun.chen wrote:
On 05/06/2013 11:10 AM, Tiejun Chen wrote:
For the external interrupt, the decrementer exception and the
doorbell
excpetion, we also need to soft-disable interrupts while doing as
host
interrupt handlers since the DO_KVM hook is always performed
On Mon, 2013-05-06 at 14:07 -0500, Ryan Arnold wrote:
> Notice that I changed DSCR to DSC. The 'R' wasn't descriptive.
The "R" is the name of the register for which we are exposing the
availability to userspace... it's also the name of the sysfs entry so
I'd rather keep it for consistency.
Cheer
On Mon, 2013-05-06 at 09:38 -0500, Ryan Arnold wrote:
> My understanding was that these bits being 'on' is an indication of
> what features the hardware supports (or what the kernel emulates) and
> a not an indication of whether that facility is currently enabled or
> not. If the hardware supports
On Mon, 2013-05-06 at 21:44 +0800, Gavin Shan wrote:
> We needn't configure IO windows for the corresponding PEs on PHB3
> since that doesn't support IO.
Here too, no need for such a flag, just check that
pci_controller->io_resource.flags is 0.
BTW. Please work on top of the patch I sent already
On Mon, 2013-05-06 at 21:44 +0800, Gavin Shan wrote:
> The patch intends to set the special flag (PCI_BUS_FLAGS_NO_IO) for
> root buses so PCI core will skip assignment for IO stuff. Besides,
> we also clear the IO resources on all PCI devices for PHB3.
Why the new hook ? Can't this be detected si
Anshuman Khandual wrote:
> On 05/06/2013 04:41 PM, Michael Neuling wrote:
> > Anshuman Khandual wrote:
> >
> >> Fixing some conditions during BHRB entry processing.
> >
> > I think we can simplify this a lot more... something like the below.
> >
>
> I feel that the conditional handling of th
On Mon, 2013-05-06 at 17:21 +1000, a...@ozlabs.ru wrote:
> From: Alexey Kardashevskiy
>
> The IOMMU API implements groups creating/deletion, device binding
> and IOMMU map/unmap operations.
>
> The PowerPC implementation uses most of the API except map/unmap
> operations, which are implemented o
From: "Aneesh Kumar K.V"
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pte-hash64-64k.h | 2 +-
arch/powerpc/kernel/pci-common.c | 5 ++---
arch/powerpc/mm/init_64.c | 3 ++-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/incl
Hi Nish,
Nishanth Aravamudan wrote on 05/03/2013 07:47:56
PM:
> +/* 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
> +#define PPC_FEATURE2_ISEL
Nishanth Aravamudan wrote on 05/03/2013 06:40:19
PM:
> Nishanth Aravamudan
> 05/03/2013 06:40 PM
>
> To
>
> Benjamin Herrenschmidt
>
> cc
>
> Michael Neuling , Michael R Meissner/
> Cambridge/IBM@IBMUS, Steve Munroe/Rochester/IBM@IBMUS, Peter
> Bergner/Rochester/IBM@IBMUS, Ryan Arnold/Rocheste
On Sun, May 5, 2013 at 11:50 PM, Benjamin Herrenschmidt
wrote:
> The PCI core supports an offset per aperture nowadays but our arch
> code still has a single offset per host bridge representing the
> difference betwen CPU memory addresses and PCI MMIO addresses.
>
> This is a problem as new machin
On 05/06/2013 04:53 AM, Tiejun Chen wrote:
Actually E500MC also support doorbell exception, and CONFIG_PPC_E500MC
can cover BOOK3E/BOOK3E_64 as well.
Signed-off-by: Tiejun Chen
---
arch/powerpc/kvm/booke.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm
On 05/06/2013 04:41 PM, Michael Neuling wrote:
> Anshuman Khandual wrote:
>
>> Fixing some conditions during BHRB entry processing.
>
> I think we can simplify this a lot more... something like the below.
>
I feel that the conditional handling of the invalid BHRB entries should be
present whic
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher wrote:
> On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
> wrote:
>> 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 p
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
wrote:
> 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
The patch intends to set the special flag (PCI_BUS_FLAGS_NO_IO) for
root buses so PCI core will skip assignment for IO stuff. Besides,
we also clear the IO resources on all PCI devices for PHB3.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/machdep.h|3 ++
arch/powerpc/kerne
We needn't configure IO windows for the corresponding PEs on PHB3
since that doesn't support IO.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/p
There has some PCI hosts (e.g. PHB3) that don't support IO. So the
patch intends to introduce the flag to indicate the special case.
In turn, we won't do IO resource assignment and enable that.
Signed-off-by: Gavin Shan
---
drivers/pci/pci.c |3 +++
drivers/pci/setup-bus.c | 25 +
On Mon, 2013-05-06 at 13:34 +0530, Anshuman Khandual wrote:
> The 'to' field inside branch entries might contain stale values from previous
> PMU interrupt instances which had indirect branches. So clear all the values
> before reading a fresh set of BHRB entries after a PMU interrupt.
>
> Signed-
Check truncate_if_32bit() on final write to nip.
Signed-off-by: Michael Neuling
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index e15c521..99c7fc1 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -580,7 +580,7 @@ int __kprobes emulate_step(struct pt_re
Anshuman Khandual wrote:
> Fixing some conditions during BHRB entry processing.
I think we can simplify this a lot more... something like the below.
Also, this marks the "to" address as all 1s, which is better poison
value since it's possible to branch to/from 0x0.
diff --git a/arch/powerpc/pe
On Mon, May 6, 2013 at 7:41 AM, Benjamin Herrenschmidt
wrote:
> Some interrupt controllers refuse to map interrupts marked as
> "protected" by firwmare. Since we try to map everyting in the
> device-tree on some platforms, we end up with a lot of nasty
> WARN's in the boot log for what is a normal
The 'to' field inside branch entries might contain stale values from previous
PMU interrupt instances which had indirect branches. So clear all the values
before reading a fresh set of BHRB entries after a PMU interrupt.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/core-book3s.c | 2 ++
The 'to' field inside branch entries might contain stale values from previous
PMU interrupt instances which had indirect branches. So clear all the values
before reading a fresh set of BHRB entries after a PMU interrupt.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/core-book3s.c | 2 ++
Fixing some conditions during BHRB entry processing.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/core-book3s.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 09db68d..1de2756 100644
--
On Mon, 2013-05-06 at 16:50 +1000, Benjamin Herrenschmidt wrote:
> We are registering the attribute with permission 0600 but it
> doesn't have a store callback, which causes WARN_ON's during
> boot. Fix the permission.
Ignore the 8/8 in the subject, that's just me not cleaning
things up properly :
This adds special support for huge pages (16MB). The reference
counting cannot be easily done for such pages in real mode (when
MMU is off) so we added a list of huge pages. It is populated in
virtual mode and get_page is called just once per a huge page.
Real mode handlers check if the requested
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests without passing them to QEMU, which should
save time on switching to QEMU and back.
Both real and virtual modes are supported - whenever the kernel
fails to handle TCE request, it passes it to the virtual
As IOMMU groups are exposed to the user space by their numbers,
the user space can use them in various kernel APIs so the kernel
might need an API to find a group by its ID.
As an example, QEMU VFIO on PPC64 platform needs it to associate
a logical bus number (LIOBN) with a specific IOMMU group in
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where eac
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 multiple entries
(up to 512) into the TCE table in one call which saves time on
transition to/from real mode.
This adds a g
The lookup_linux_pte() function returns a linux PTE which is needed in
the process of converting KVM guest physical address into host real
address in real mode.
This conversion will be used by upcoming support of H_PUT_TCE_INDIRECT,
as the TCE list address comes from the guest and is a guest physi
This series is supposed to accelerate IOMMU operations in real and virtual
mode in the host kernel for the KVM guest.
The first user is VFIO however this series does not contain any VFIO related
code as the connection between VFIO and the new handlers is to be made in QEMU
via ioctl to the KVM fd.
From: Alexey Kardashevskiy
The enables VFIO on the pSeries platform, enabling user space
programs to access PCI devices directly.
Signed-off-by: Alexey Kardashevskiy
Cc: David Gibson
Signed-off-by: Paul Mackerras
---
arch/powerpc/platforms/pseries/iommu.c |4
drivers/iommu/Kconfig
From: Alexey Kardashevskiy
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This implements an IOMMU driver
From: Alexey Kardashevskiy
This initializes IOMMU groups based on the IOMMU configuration
discovered during the PCI scan on POWERNV (POWER non virtualized)
platform. The IOMMU groups are to be used later by the VFIO driver,
which is used for PCI pass through.
It also implements an API for mappi
From: Alexey Kardashevskiy
The IOMMU API implements groups creating/deletion, device binding
and IOMMU map/unmap operations.
The PowerPC implementation uses most of the API except map/unmap
operations, which are implemented on POWER using hypercalls.
However, in order to link a kernel with the
From: Alexey Kardashevskiy
The iommu_init() call initializes IOMMU internal structures and data
required for the API to function such as iommu_group_alloc().
It is registered as a subsys_initcall.
One of the IOMMU users is a PCI subsystem on POWER which discovers new
IOMMU tables during the PCI
From: Alexey Kardashevskiy
The series adds support for VFIO on POWERPC in user space (such as QEMU).
The in-kernel real mode IOMMU support is added by another series posted
separately.
As the first and main aim of this series is the POWERNV platform support,
the "Enable on POWERNV platform" patc
65 matches
Mail list logo
