PR KVM page fault handler performs eaddr to pte translation for a guest,
however kvmppc_mmu_book3s_64_xlate() does not preserve WIMG bits
(storage control) in the kvmppc_pte struct. If PR KVM is running as
a second level guest under HV KVM, and PR KVM tries inserting HPT entry,
this fails in HV KVM
At the moment kvmppc_mmu_map_page() returns -1 if
mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler
resumes the guest and it faults on the same address again.
This adds distinction to kvmppc_mmu_map_page() to return -EIO if
mmu_hash_ops.hpte_insert() failed for a reason oth
@is_mmio has never been used since introduction in
commit 2f4cf5e42d13 ("Add book3s.c") from 2009.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kvm/book3s_pr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
This enables VFIO on pseries host in order to allow VFIO in nested guest
under PR KVM or DPDK in a HV guest. This adds support of
the VFIO_SPAPR_TCE_IOMMU type.
This adds exchange() callback to allow TCE updates by the SPAPR TCE IOMMU
driver in VFIO.
This initializes DMA32 window parameters in io
On Mon, Mar 20, 2017 at 05:49:08PM +1100, Benjamin Herrenschmidt wrote:
> The XIVE interrupt controller is the new interrupt controller
> found in POWER9. It supports advanced virtualization capabilities
> among other things.
>
> Currently we use a set of firmware calls that simulate the old
> "XI
On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> Define helpers to initialize window context registers of the VAS
> hardware. These will be used in follow-on patches when opening/closing
> VAS windows.
>
> Signed-off-by: Sukadev Bhattiprolu
> ---
> Changelog[v3]
> - Have call
On Thu, Mar 23, 2017 at 02:01:50PM +0200, Daniel Baluta wrote:
> From: Nicolin Chen
>
> WM8962 needs its MCLK when powerup in wm8962_resume(). Thus it's better
> to control the MCLK in codec driver. Thus remove the clock enable in
> machine dirver accordingly.
>
> While at it, get rid of imx_wm8
On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> Define some helper functions to access the MMIO regions. We use these
> in a follow-on patches to read/write VAS hardware registers. These
> helpers are also used to later issue 'paste' instructions to submit
> requests to the NX hardw
Hi,
Could you please revise the subject a bit? I forgot what's the
original one I submitted (internally) years ago. But the patch
is for imx-wm8962 instead of WM8962.
So please use
ASoC: fsl: imx-wm8962:
or at least
ASoC: imx-wm8962:
The change itself looks fine though.
Thanks
Nic
O
On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> Implement vas_init() and vas_exit() functions for a new VAS module.
> This VAS module is essentially a library for other device drivers
> and kernel users of the NX coprocessors like NX-842 and NX-GZIP.
>
> Signed-off-by: Sukadev Bhat
Michael Neuling [michael.neul...@au1.ibm.com] wrote:
> On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3673,8 +3673,6 @@ F:arch/powerpc/platforms/powernv/pci-cxl.c
> > F: drivers/misc/cxl/
> > F: include/misc/cxl*
>
On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> Define macros for the VAS hardware registers and bit-fields as well
> as couple of data structures needed by the VAS driver.
>
> > Signed-off-by: Sukadev Bhattiprolu
> ---
> Changelog[v3]
> - Rename winctx->pid to winctx->pidr
On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3673,8 +3673,6 @@ F:arch/powerpc/platforms/powernv/pci-cxl.c
> F: drivers/misc/cxl/
> F: include/misc/cxl*
> F: include/uapi/misc/cxl.h
> -F: Documentation/powerpc/
POWER9 adds form 1 scoms. The form of the indirection is specified in
the top nibble of the scom address.
Currently we do some (ugly) bit mangling so that we can fit a 64 bit
scom address into the debugfs interface. The current code only shifts
the top bit (indirect bit).
This patch changes it to
On 03/23/2017 07:47 PM, Pasha Tatashin wrote:
How long does it take if we just don't zero this memory at all? We seem
to be initialising most of struct page in __init_single_page(), so it
seems like a lot of additional complexity to conditionally zero the rest
of struct page.
Alternatively,
On 03/23/2017 07:35 PM, David Miller wrote:
From: Matthew Wilcox
Date: Thu, 23 Mar 2017 16:26:38 -0700
On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote:
When deferred struct page initialization feature is enabled, we get a
performance gain of initializing vmemmap in parallel a
Hi Matthew,
Thank you for your comment. If you look at the data, having memset()
actually benefits initializing data.
With base it takes:
[ 66.148867] node 0 initialised, 128312523 pages in 7200ms
With fix:
[ 15.260634] node 0 initialised, 128312523 pages in 4190ms
So 4.19s vs 7.2s for t
Allow clients to request non-zeroed memory from vmemmap allocator.
The following two public function have a new boolean argument called zero:
__vmemmap_alloc_block_buf()
vmemmap_alloc_block()
When zero is true, memory that is allocated by memblock allocator is zeroed
(the current behavior), when
A new version of memblock_virt_alloc_* allocations:
- Does not zero the allocated memory
- Does not panic if request cannot be satisfied
Signed-off-by: Pavel Tatashin
Reviewed-by: Shannon Nelson
---
include/linux/bootmem.h |3 +++
mm/memblock.c | 46 +
When deferred struct page initialization is enabled, do not expect that
the memory that was allocated for struct pages was zeroed by the
allocator. Zero it when "struct pages" are initialized.
Also, a defined boolean VMEMMAP_ZERO is provided to tell platforms whether
they should zero memory or can
Remove duplicating code, by using common functions
vmemmap_pud_populate and vmemmap_pgd_populate functions.
Signed-off-by: Pavel Tatashin
Reviewed-by: Shannon Nelson
---
arch/sparc/mm/init_64.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/
When deferred struct page initialization feature is enabled, we get a
performance gain of initializing vmemmap in parallel after other CPUs are
started. However, we still zero the memory for vmemmap using one boot CPU.
This patch-set fixes the memset-zeroing limitation by deferring it as well.
Her
If we are using deferred struct page initialization feature, most of
"struct page"es are getting initialized after other CPUs are started, and
hence we are benefiting from doing this job in parallel. However, we are
still zeroing all the memory that is allocated for "struct pages" using the
boot CP
From: Matthew Wilcox
Date: Thu, 23 Mar 2017 16:26:38 -0700
> On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote:
>> When deferred struct page initialization feature is enabled, we get a
>> performance gain of initializing vmemmap in parallel after other CPUs are
>> started. However, w
On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote:
> When deferred struct page initialization feature is enabled, we get a
> performance gain of initializing vmemmap in parallel after other CPUs are
> started. However, we still zero the memory for vmemmap using one boot CPU.
> This pat
On Thu, Mar 23, 2017 at 03:53:42PM -0500, Bjorn Helgaas wrote:
> Hi Yongji,
>
> On Wed, Feb 15, 2017 at 02:45:05PM +0800, Yongji Xie wrote:
> > When vfio passthroughs a PCI device of which MMIO BARs are
> > smaller than PAGE_SIZE, guest will not handle the mmio
> > accesses to the BARs which leads
On Wed, Feb 15, 2017 at 02:45:06PM +0800, Yongji Xie wrote:
> Currently we reassign the alignment by extending resources' size in
> pci_reassigndev_resource_alignment(). This could potentially break
> some drivers when the driver uses the size to locate register
> whose length is related to the siz
Hi Yongji,
On Wed, Feb 15, 2017 at 02:45:05PM +0800, Yongji Xie wrote:
> When vfio passthroughs a PCI device of which MMIO BARs are
> smaller than PAGE_SIZE, guest will not handle the mmio
> accesses to the BARs which leads to mmio emulations in host.
>
> This is because vfio will not allow to pa
Hi Maddy, Anju,
On Thu, Mar 16, 2017 at 01:05:06PM +0530, Madhavan Srinivasan wrote:
> From: Anju T Sudhakar
>
> This patch adds support for thread IMC on cpuhotplug.
>
> When a cpu goes offline, the LDBAR for that cpu is disabled, and when it comes
> back online the previous ldbar value is wri
Hi Michael,
It's been a while since this patchset is Ack'ed.
Should this go through powerpc-tree or some other?
Thanks
Hari
On Thursday 05 January 2017 10:59 PM, Hari Bathini wrote:
Traditionally, kdump is used to save vmcore in case of a crash. Some
architectures like powerpc can save vmcore
* Rafael J. Wysocki [2017-03-23 16:28:31]:
> On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan
> wrote:
> > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init().
> > On PowerNV platform cpu_present could be less than cpu_possible in cases
> > where firmware detects the cp
* Rafael J. Wysocki [2017-03-23 16:27:31]:
> On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan
> wrote:
> > If a given cpu is not in cpu_present and cpu hotplug
> > is disabled, arch can skip setting up the cpu_dev.
> >
> > Arch cpuidle driver should pass correct cpu mask
> > for registra
On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan
wrote:
> drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init().
> On PowerNV platform cpu_present could be less than cpu_possible in cases
> where firmware detects the cpu, but it is not available to the OS. When
> CONFIG_HO
On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan
wrote:
> If a given cpu is not in cpu_present and cpu hotplug
> is disabled, arch can skip setting up the cpu_dev.
>
> Arch cpuidle driver should pass correct cpu mask
> for registration, but failing to do so by the driver
> causes error to
If a given cpu is not in cpu_present and cpu hotplug
is disabled, arch can skip setting up the cpu_dev.
Arch cpuidle driver should pass correct cpu mask
for registration, but failing to do so by the driver
causes error to propagate and crash like this:
[ 30.076045] Unable to handle kernel pagin
drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init().
On PowerNV platform cpu_present could be less than cpu_possible in cases
where firmware detects the cpu, but it is not available to the OS. When
CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence
we skip c
When CONFIG_HOTPLUG_CPU=n and cpu_present is less than cpu_possible,
then cpuidle-powernv not passing an explicit drv->cpu_mask allows
generic cpuidle driver to try create sysfs objects for cpus that does
not have cpu_devices created by calling register_cpu().
This caused kernel to access incorrec
Hi Maddy, Hemant, Anju,
On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote:
[..snip..]
> +
> +static void core_imc_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + if (!core_imc_pmu)
> + return;
> + perf_pmu_migrate_context(&core_imc_pmu->pmu, old_cpu, n
From: Nicolin Chen
WM8962 needs its MCLK when powerup in wm8962_resume(). Thus it's better
to control the MCLK in codec driver. Thus remove the clock enable in
machine dirver accordingly.
While at it, get rid of imx_wm8962_remove function since it is now
empty.
Signed-off-by: Nicolin Chen
Sign
Hi Hemant, Maddy,
On Thu, Mar 16, 2017 at 01:05:00PM +0530, Madhavan Srinivasan wrote:
> From: Hemant Kumar
>
> Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any
> online CPU) from each chip for nest PMUs is designated to read counters.
>
> On CPU hotplug, dying CPU is check
Currently the code to perform an OPAL call is duplicated between the
normal path and path taken when tracepoints are enabled. There's no
real need for this and combining them makes opal_tracepoint_entry
considerably easier to understand.
Signed-off-by: Oliver O'Halloran
---
v1 -> v2:
slig
Nicholas Piggin writes:
> On Tue, 21 Mar 2017 15:42:22 +1100
> Stewart Smith wrote:
>
>> Nicholas Piggin writes:
>> > With this patch and the Linux one, I can boot (in mambo) a POWER8 or
>> > POWER9 without looking up any cpu tables, and mainly looking at PVR
>> > for MCE and PMU.
>>
>> That'
43 matches
Mail list logo
