On 05/01/2015 03:12 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:10:58PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015 04:40 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:51PM +1000, Alexey Kardashevskiy wrote:
This adds a way for the IOMMU user to know how much a new table wi
From: Sam Bobroff
Patches 7cba160ad "powernv/cpuidle: Redesign idle states management"
and 77b54e9f2 "powernv/powerpc: Add winkle support for offline cpus"
use non-volatile condition registers (cr2, cr3 and cr4) early in the system
reset interrupt handler (system_reset_pSeries()) before it has be
On 05/01/2015 03:23 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:35:23PM +1000, Alexey Kardashevskiy wrote:
On 04/30/2015 04:55 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:53PM +1000, Alexey Kardashevskiy wrote:
The existing implementation accounts the whole DMA window in
the l
On 05/01/2015 02:33 PM, David Gibson wrote:
On Thu, Apr 30, 2015 at 07:33:09PM +1000, Alexey Kardashevskiy wrote:
On 04/30/2015 05:22 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
At the moment only one group per container is supported.
POWER8 CP
The requirement is raised when developing the PCI hotplug feature
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
When plugging PCI adapter to one PCI slot, the firmware rescans the
slot and build FDT (Flat Device Tree) blob, which is sent to the
PowerNV PCI hotplug driver for
During the PCI plugging event, the PCI devices are rescanned and
their IO and MMIO resources are reassigned. However, the PowerNV
platform will assign PE# based on that, which depends on updating
to window of bridge of the PE's primary bus.
The patch updates the windows of bridge of PE's primary b
The patch exports 3 functions, which base on corresponding OPAL
APIs to get or set PCI slot status. Those functions are going to
be used by PCI hotplug module in subsequent patches:
pnv_pci_get_presence_status() opal_pci_get_presence_status()
pnv_pci_get_power_status() opal_pci_get_powe
We might not get some PCI slot information (e.g. power status)
immediately by OPAL API. Instead, opal_pci_poll() need to be called
for the required information.
The patch introduces pnv_pci_poll(), which bases on original
pnv_eeh_poll(), to cover the above case
Signed-off-by: Gavin Shan
---
arc
The patch moves pcibios_find_pci_bus() to PPC kerenl directory so
that it can be reused by hotplug code for pSeries and PowerNV
platform at the same time.
Signed-off-by: Gavin Shan
Acked-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/pci-hotplug.c | 36 +
In hotplug case, function pcibios_add_pci_devices() is called to
rescan the specified PCI bus, which might not have any child devices.
Access to the PCI bus's child device node will cause kernel crash
without exception. The patch adds condition of skipping scanning
PCI bus without child devices, in
Function pnv_pci_reset_secondary_bus() is used to reset specified
PCI bus, which is leaded by root complex or PCI bridge. That means
the function shouldn't be called on PCI root bus and the patch
removes the logic for that case.
Also, some adapters beneath the indicated PCI bus may require
fundame
The original code doesn't support releasing PEs dynamically, meaning
that PE and the associated resources (IO, M32, M64 and DMA) can't
be released when unplugging a PCI adapter from one hotpluggable slot.
The patch takes object oriented methodology, introducs reference
count to PE, which is initia
The patch exports following functions, which are derived from their
original implementation, so that the PCI hotplug logic can reuse
the functions to add or remove pci_dn for all device nodes under
specified PCI slot.
traverse_pci_device_nodes() traverse_pci_devices()
add_pci_device_node
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup(). The function is called for once after
PCI probing and resources assignment are finished. Obviously, it's
not hotplug friendly. The patch creates PEs dynamically by
ppc_md.pcibios_setup_bridge(), which is calle
The patch intends to add standalone driver to support PCI hotplug
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
The firmware identified hotpluggable slots and marked their device
tree node with proper "ibm,slot-pluggable" and "ibm,reset-by-firmware".
The driver simply scans d
The device tree nodes will be changed dynamically on PCI hotplug
events on PowerNV platform. The patch selects OF_DYNAMIC on the
platform to support PCI hotplug.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/
Nobody is using the this function. The patch drops it.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 71 ---
1 file changed, 71 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is evenly divided into 256MB segments. How many
continuous segments assigned to one particular PE depends on
the PE's DMA weight that is figured out from the type of each
PCI devices contained in the PE, and PHB's DMA weigh
For PowerNV platform, running on top of skiboot, all PE level reset
should be routed to firmware if the bridge of the PE primary bus has
device-node property "ibm,reset-by-firmware". Otherwise, the kernel
has to issue hot reset on PE's primary bus despite the requested reset
types, which is the beh
The pci_dn instances are allocated from memblock or bootmem when
creating PCI controller (hoses) in setup_arch(). The PCI hotplug,
which will be supported by proceeding patches, will release PCI
device nodes and their corresponding pci_dn on unplugging event.
The pci_dn instance memory chunks alloe
The eeh_dev is always created based on pci_dn, but with initcall
supported by core_initcall_sync(). The patch creates eeh_dev
when pci_dn is created, indicating they have same life cycle.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 6 --
arch/powerpc/kernel/eeh_de
We're having the hardware or enforced (on P7IOC) limitation: M64
segment#x can only be assigned to PE#x. IO and M32 segment can be
mapped to arbitrary PE# via IODT and M32DT. It means the PE number
should be x if M64 segment#x has been assigned to the PE. Also, each
PE own one M64 segment at most.
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Comparing to PHB3, there are 16 M64 BARs and each of them
are divided to 8 segments. So each PHB can support 128 M64 segments.
Also, P7IOC has M64DT, which helps mapping one particular M64
segment# to arbitrary PE#. However, we
The PHB's IO or M32 window is divided evenly to segments, each of
them can be mapped to arbitrary PE# by IODT or M32DT. Current code
figures out the consumed IO and M32 segments by one particular PE
from the windows of the PE's upstream bridge. It won't be reliable
once we extend M64 windows of roo
Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
which is called for once after PCI probing and resource assignment
are completed, to allocate platform required resources for PCI devices:
PE#, IO and MMIO mapping, DMA address translation (TCE) table etc.
Obviously, it's not hotp
The series of patches intend to support PCI slot for PowerPC PowerNV platform,
which is running on top of skiboot firmware. The patchset requires corresponding
changes from skiboot firmware, which is sent to skib...@lists.ozlabs.org
for review. The PCI slots are exposed by skiboot with device node
With the new thp refcounting we don't need to mark the PMD splitting.
Drop the code to handle this.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s_64.h | 6 --
arch/powerpc/include/asm/pgtable-ppc64.h | 29 ++--
arch/powerpc/mm/hugepage-hash64.c| 3 -
ar
Some arch may require an explicit IPI before a THP PMD split or
collapse. This enable us to use local_irq_disable to prevent
a parallel THP PMD split or collapse.
Signed-off-by: Aneesh Kumar K.V
---
include/asm-generic/pgtable.h | 32
mm/huge_memory.c
The changes are on top of what is posted at
http://mid.gmane.org/1429823043-157133-1-git-send-email-kirill.shute...@linux.intel.com
git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git thp/refcounting/v5
Changes from V1:
* Fold part of patch 3 to 1 and 2
* Drop patch 3.
* Make generic
On Fri, May 01, 2015 at 02:35:23PM +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 04:55 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:53PM +1000, Alexey Kardashevskiy wrote:
> >>The existing implementation accounts the whole DMA window in
> >>the locked_vm counter. This is going to b
On Fri, May 01, 2015 at 02:10:58PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 04:40 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:51PM +1000, Alexey Kardashevskiy wrote:
> >>This adds a way for the IOMMU user to know how much a new table will
> >>use so it can be accounted in the
This patch updates Arasan SDHC documentation to support
4.9a version of Arasan SDHC controller.
Signed-off-by: Suman Tripathi
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/
This patch adds the quirks and compatible string in sdhci-of-arasan.c
to support sdhci-arasan4.9a version of controller.
Signed-off-by: Suman Tripathi
---
drivers/mmc/host/sdhci-of-arasan.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/m
This patch adds the arasan sdhc nodes to reuse the of-arasan
driver for APM X-Gene SoC.
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-mustang.dts | 4
arch/arm64/boot/dts/apm-storm.dtsi | 44 +
2 files changed, 48 insertions(+)
diff --git a
This patch adds the SDHCI support for APM X-Gene SoC using ARASAN SDHCI
controller.
v1 change:
* Use the CONFIG_ARM64_DMA_HAS_IOMMU for dma-mapping.
v2 change:
* Drop the IOMMU support and switching to PIO mode for arasan.
controller integrated inside APM X-Gene SoC.
v3 change:
* Change t
On Thu, Apr 30, 2015 at 07:33:09PM +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 05:22 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> >>At the moment only one group per container is supported.
> >>POWER8 CPUs have more flexible design and all
On Fri, May 01, 2015 at 02:01:17PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 04:31 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:50PM +1000, Alexey Kardashevskiy wrote:
> >>In order to support memory pre-registration, we need a way to track
> >>the use of every registered memory
On Fri, May 01, 2015 at 10:46:08AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-04-30 at 19:33 +1000, Alexey Kardashevskiy wrote:
> > On 04/30/2015 05:22 PM, David Gibson wrote:
> > > On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> > >> At the moment only one group pe
Commit ff57b454ddb9 ("powerpc/eeh: Do probe on pci_dn") probes EEH
devices in early stage, which is reasonable to pSeries platform.
However, it's wrong for PowerNV platform because the PE# isn't
determined until the resources (IO and MMIO) are assigned to PE in
hotplug case. So we have to delay pro
On 04/30/2015 04:55 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:53PM +1000, Alexey Kardashevskiy wrote:
The existing implementation accounts the whole DMA window in
the locked_vm counter. This is going to be worse with multiple
containers and huge DMA windows. Also, real-time accountin
On 04/29/2015 04:40 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:51PM +1000, Alexey Kardashevskiy wrote:
This adds a way for the IOMMU user to know how much a new table will
use so it can be accounted in the locked_vm limit before allocation
happens.
This stores the allocated table siz
On Fri, May 01, 2015 at 01:51:37PM +1000, Michael Ellerman wrote:
>On Fri, 2015-05-01 at 11:28 +1000, Gavin Shan wrote:
>> On Fri, May 01, 2015 at 09:50:57AM +1000, Michael Ellerman wrote:
>> >On Fri, 2015-05-01 at 09:22 +1000, Gavin Shan wrote:
>> >> Commit 1c509148b ("powerpc/eeh: Do probe on pci
On 04/29/2015 04:31 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:50PM +1000, Alexey Kardashevskiy wrote:
In order to support memory pre-registration, we need a way to track
the use of every registered memory region and only allow unregistration
if a region is not in use anymore. So we n
On Fri, 2015-05-01 at 11:23 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > Traffic on the cbe-oss-dev list is more or less non-existent, other than
> > CC's from linuxppc.
>
> Plus all that spam that never makes it out of the moderation queue.
>
> > It's seems like we may as well just send everyo
On Thu, Apr 30, 2015 at 06:25:25PM +1000, Paul Mackerras wrote:
> On Thu, Apr 30, 2015 at 04:34:55PM +1000, David Gibson wrote:
> > On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
> > > We are adding support for DMA memory pre-registration to be used in
> > > conjunction with
On Thu, Apr 30, 2015 at 07:56:17PM +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 02:37 PM, David Gibson wrote:
> >On Wed, Apr 29, 2015 at 07:44:20PM +1000, Alexey Kardashevskiy wrote:
> >>On 04/29/2015 03:30 PM, David Gibson wrote:
> >>>On Sat, Apr 25, 2015 at 10:14:47PM +1000, Alexey Kardashe
On Fri, 2015-05-01 at 11:28 +1000, Gavin Shan wrote:
> On Fri, May 01, 2015 at 09:50:57AM +1000, Michael Ellerman wrote:
> >On Fri, 2015-05-01 at 09:22 +1000, Gavin Shan wrote:
> >> Commit 1c509148b ("powerpc/eeh: Do probe on pci_dn") probes EEH
> >> devices in early stage, which is reasonable to p
Hi Ben,
>> +static LIST_HEAD(opal_prd_msg_queue);
>> +static DEFINE_SPINLOCK(opal_prd_msg_queue_lock);
>> +static DECLARE_WAIT_QUEUE_HEAD(opal_prd_msg_wait);
>> +static atomic_t usage;
>
> opal_prd_usage ... otherwise it's a mess in the symbols map
OK, I'll change this.
> Also why limit the nu
Hi Michael,
> Traffic on the cbe-oss-dev list is more or less non-existent, other than
> CC's from linuxppc.
Plus all that spam that never makes it out of the moderation queue.
> It's seems like we may as well just send everyone to linuxppc and
> archive the list.
Acked-by: Jeremy Kerr
[This'
Traffic on the cbe-oss-dev list is more or less non-existent, other than
CC's from linuxppc.
It's seems like we may as well just send everyone to linuxppc and
archive the list.
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --g
On Fri, May 01, 2015 at 09:50:57AM +1000, Michael Ellerman wrote:
>On Fri, 2015-05-01 at 09:22 +1000, Gavin Shan wrote:
>> Commit 1c509148b ("powerpc/eeh: Do probe on pci_dn") probes EEH
>> devices in early stage, which is reasonable to pSeries platform.
>> However, it's wrong for PowerNV platform
On Thu, 2015-04-30 at 19:33 +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 05:22 PM, David Gibson wrote:
> > On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> >> At the moment only one group per container is supported.
> >> POWER8 CPUs have more flexible design and allows
On Fri, 2015-05-01 at 09:22 +1000, Gavin Shan wrote:
> Commit 1c509148b ("powerpc/eeh: Do probe on pci_dn") probes EEH
> devices in early stage, which is reasonable to pSeries platform.
> However, it's wrong for PowerNV platform because the PE# isn't
> determined until the resources (IO and MMIO) a
On Thu, 2015-04-30 at 14:58 -0700, Tyrel Datwyler wrote:
> On 04/29/2015 06:44 PM, Nathan Fontenot wrote:
> > Failure return from dlpar_configure_connector when dlpar adding cpus
> > results in leaking references to the cpus parent device node. Move the
> > call to of_node_put() prior to checking t
Commit 1c509148b ("powerpc/eeh: Do probe on pci_dn") probes EEH
devices in early stage, which is reasonable to pSeries platform.
However, it's wrong for PowerNV platform because the PE# isn't
determined until the resources (IO and MMIO) are assigned to
PE in hotplug case. So we have to delay probin
When asserting reset in pcibios_set_pcie_reset_state(), the PE
is enforced to (hardware) frozen state in order to drop unexpected
PCI transactions (except PCI config read/write) automatically by
hardware during reset, which would cause recursive EEH error.
However, the (software) frozen state EEH_P
On 04/29/2015 06:44 PM, Nathan Fontenot wrote:
> Failure return from dlpar_configure_connector when dlpar adding cpus
> results in leaking references to the cpus parent device node. Move the
> call to of_node_put() prior to checking the result of
> dlpar_configure_connector.
>
> Fixes: 8d5ff320766
Hi Alistair,
Applied all of the patches on top of 'v4.0-rc7', found this issue during
the boot itself http://pastebin.hursley.ibm.com/918.
There are few compile warnings and minor comments.
drivers/tty/hvc/hvc_opal.c: In function ‘hvc_opal_probe’:
drivers/tty/hvc/hvc_opal.c:174:6: warning: unus
Hi Alistair,
With all the patches applied on top of 'v4.0-rc7', I see this issue during
the boot itself http://pastebin.hursley.ibm.com/918
Few compile warnings and minor comments.
drivers/tty/hvc/hvc_opal.c: In function ‘hvc_opal_probe’:
drivers/tty/hvc/hvc_opal.c:174:6: warning: unused variabl
From: Thomas Falcon
Date: Wed, 29 Apr 2015 16:25:47 -0500
> Enables receiving large packets from other LPARs. These packets
> have a -1 IP header checksum, so we must recalculate to have
> a valid checksum.
>
> Signed-off-by: Brian King
> Signed-off-by: Thomas Falcon
> ---
> v3:
> -Removed co
From: Thomas Falcon
Date: Wed, 29 Apr 2015 16:25:46 -0500
> Cc: Brian King
> Signed-off-by: Thomas Falcon
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
From: Thomas Falcon
Date: Wed, 29 Apr 2015 16:25:45 -0500
> Add support for TSO. TSO is turned off by default and
> must be enabled and configured by the user. The driver
> version number is increased so that users can be sure
> that they are using ibmveth with TSO support.
>
> Cc: Brian King
From: Thomas Falcon
Date: Wed, 29 Apr 2015 16:25:44 -0500
> This patch enables 64k rx buffer pools by default. If Cooperative
> Memory Overcommitment (CMO) is enabled, the number of 64k buffers
> is reduced to save memory.
>
> Cc: Brian King
> Signed-off-by: Thomas Falcon
Applied.
__
On Fri, May 1, 2015 at 1:18 AM, Mike Snitzer wrote:
>> I just booted 3d99e3fe13d473ac4578c37f477a59b829530764 (linus' tree as
>> of this morning) on a Tuletta and got the following:
>
> This is fixed with the following commit (which I just sent to Linus for
> 4.1-rc2 inclusion):
> https://git.kern
On Wed, Apr 29 2015 at 11:29pm -0400,
Joel Stanley wrote:
> Hello,
>
> I just booted 3d99e3fe13d473ac4578c37f477a59b829530764 (linus' tree as
> of this morning) on a Tuletta and got the following:
This is fixed with the following commit (which I just sent to Linus for
4.1-rc2 inclusion):
https:
On 04/30/2015 07:59 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
Hi Jacek,
.../...
>> diff --git a/Documentation/devicetree/bindings/leds/leds-powernv.txt
>> b/Documentation/devicetree/bindings/leds/leds-powernv.txt
>> new file mode 100644
>> index 000..6bb0e7e
>> --- /dev/null
>> +++ b/Docu
On 04/28/2015 03:48 PM, Arnd Bergmann wrote:
> On Tuesday 28 April 2015 15:40:35 Vasant Hegde wrote:
>> +++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
>> @@ -0,0 +1,29 @@
>> +Device Tree binding for LEDs on IBM Power Systems
>> +-
>> +
Hi Vasant,
On 04/28/2015 12:10 PM, Vasant Hegde wrote:
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, April 30, 2015 3:31 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> Yuantian-B29983
> Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for
In preparation for libfdt/dtc update, add the new fdt specific types.
Signed-off-by: Rob Herring
Cc: Russell King
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/arm/boot/compressed/libfdt_
It makes no sense to keep two separate RELOCATABLE config entries for
ppc32 and ppc64 respectively. Merge them into one and move it to
a common place. The dependency on ADVANCED_OPTIONS for ppc32 seems
unnecessary, also drop it.
Signed-off-by: Kevin Hao
---
arch/powerpc/Kconfig | 65
In the current code, the RELOCATABLE will be forcedly enabled when
enabling CRASH_DUMP. But for ppc32, the RELOCABLE also depend on
ADVANCED_OPTIONS and select NONSTATIC_KERNEL. This will cause build
error when CRASH_DUMP=y && ADVANCED_OPTIONS=n. Even there is no such
issue for ppc64, but select is
Hi,
The first patch fixes a build error when CRASH_DUMP=y && ADVANCED_OPTIONS=n
for ppc32. The second does some cleanup for RELOCATABLE option.
Kevin Hao (2):
powerpc: fix the dependency issue for CRASH_DUMP
powerpc: merge the RELOCATABLE config entries for ppc32 and ppc64
arch/powerpc/Kcon
From: Igal Liberman
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming
Signed-off-by: Igal Liberman
Signed-off-by: Shruti Kanetkar
Signed-off-by: Emil Medve
---
v3: Fixed incorrect E-Mail address (signed-off-by)
v2: Remove
On 04/30/2015 02:37 PM, David Gibson wrote:
On Wed, Apr 29, 2015 at 07:44:20PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015 03:30 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:47PM +1000, Alexey Kardashevskiy wrote:
This extends iommu_table_group_ops by a set of callbacks to suppor
On 04/30/2015 05:22 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
At the moment only one group per container is supported.
POWER8 CPUs have more flexible design and allows naving 2 TCE tables per
IOMMU group so we can relax this limitation and supp
On Thu, Apr 30, 2015 at 04:34:55PM +1000, David Gibson wrote:
> On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
> > We are adding support for DMA memory pre-registration to be used in
> > conjunction with VFIO. The idea is that the userspace which is going to
> > run a guest m
This patch introduces some functions for converting cputime to timespec64 and
back,
that repalce the timespec type with timespec64 type, as well as for arch/s390
and
arch/powerpc architecture.
And these new methods will replace the old
cputime_to_timespec/timespec_to_cputime
function to ready f
This patch series changes the 32-bit time type (timespec/itimerspec) to the
64-bit one
(timespec64/itimerspec64), since 32-bit time types will break in the year 2038.
This patch series introduces new methods with timespec64/itimerspec64 type,
and removes the old ones with timespec/itimerspec type
On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> At the moment only one group per container is supported.
> POWER8 CPUs have more flexible design and allows naving 2 TCE tables per
> IOMMU group so we can relax this limitation and support multiple groups
> per container.
It'
On Sat, Apr 25, 2015 at 10:14:54PM +1000, Alexey Kardashevskiy wrote:
> A table group might not have a table but it always has the default 32bit
> window parameters so use these.
>
> No change in behavior is expected.
>
> Signed-off-by: Alexey Kardashevskiy
It would be easier to review if you t
On Sat, Apr 25, 2015 at 10:14:53PM +1000, Alexey Kardashevskiy wrote:
> The existing implementation accounts the whole DMA window in
> the locked_vm counter. This is going to be worse with multiple
> containers and huge DMA windows. Also, real-time accounting would requite
> additional tracking of
On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
> We are adding support for DMA memory pre-registration to be used in
> conjunction with VFIO. The idea is that the userspace which is going to
> run a guest may want to pre-register a user space memory region so
> it all gets pi
83 matches
Mail list logo
