On 03.02.15 06:44, David Gibson wrote:
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real
//git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next
KVM PPC bits are:
Acked-by: Alexander Graf
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
/git/borntraeger/linux.git linux-next
KVM PPC bits are:
Acked-by: Alexander Graf ag...@suse.de
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11.11.14 11:33, Ming Lei wrote:
> This patch converts the generic host controller driver
> into a more generic one, and basically don't need
> platform's pcibios support, and use DT based generic
> APIs to parse resource and remap IO port.
>
> This patch has been tested on both ARMv7 and ARMv8
On 11.11.14 11:33, Ming Lei wrote:
This patch converts the generic host controller driver
into a more generic one, and basically don't need
platform's pcibios support, and use DT based generic
APIs to parse resource and remap IO port.
This patch has been tested on both ARMv7 and ARMv8
VM,
On 07.12.14 23:29, Rickard Strandqvist wrote:
> Remove the function inst_set_field() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Thanks, applied all unused function patches in KVM
On 07.12.14 23:29, Rickard Strandqvist wrote:
Remove the function inst_set_field() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Thanks, applied all
something not a structure or union
Looking at the offending line of code I'm not surprised:
- __get_cpu_var(pcpu_sids).entry[sid] = entry;
+ __this_cpu_write(pcpu_sids)entry[sid], entry);
This doesn't quite look like valid C to me. The patch below fixes the
b
], entry);
This doesn't quite look like valid C to me. The patch below fixes the
build error for me. Please check whether it's correct and if so apply it
directly to the tree.
Alex
From: Alexander Graf ag...@suse.de
Date: Tue, 16 Dec 2014 23:04:01 +0100
Subject: [PATCH] KVM: PPC: E500: Compile fix
On 08.12.14 11:10, Will Deacon wrote:
> On Sat, Dec 06, 2014 at 05:23:59PM +0000, Alexander Graf wrote:
>> On 04.12.14 19:20, Will Deacon wrote:
>>> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>>>> With binutils 2.25 the default alignment
On 08.12.14 11:10, Will Deacon wrote:
On Sat, Dec 06, 2014 at 05:23:59PM +, Alexander Graf wrote:
On 04.12.14 19:20, Will Deacon wrote:
On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
With binutils 2.25 the default alignment for 32bit arm sections changed to
have
On 04.12.14 19:20, Will Deacon wrote:
> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run suc
On 04.12.14 19:20, Will Deacon wrote:
On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
With binutils 2.25 the default alignment for 32bit arm sections changed to
have everything 64k aligned. Armv7 binaries built with this binutils version
run successfully on an arm64 system
On 05.12.14 11:39, Arnd Bergmann wrote:
> On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
>> On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf wrote:
>>> On 04.12.14 22:15, Olof Johansson wrote:
>>>> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf w
On 05.12.14 11:39, Arnd Bergmann wrote:
On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf ag...@suse.de wrote:
On 04.12.14 22:15, Olof Johansson wrote:
On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf ag...@suse.de wrote:
With binutils
make sense to block people from enabling
CONFIG_COMPAT on those configurations.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- add comment in KConfig explaining that segments need to be 64k aligned
- conditionalize the option on EXPERT
---
arch/arm64/Kconfig | 6 +-
1 file changed
On 04.12.14 22:15, Olof Johansson wrote:
> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run successful
On 04.12.14 19:20, Will Deacon wrote:
> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run suc
make sense to block people from enabling
CONFIG_COMPAT on those configurations.
Signed-off-by: Alexander Graf
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..3cf4f238 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64
make sense to block people from enabling
CONFIG_COMPAT on those configurations.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..3cf4f238 100644
--- a/arch/arm64/Kconfig
+++ b
On 04.12.14 19:20, Will Deacon wrote:
On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
With binutils 2.25 the default alignment for 32bit arm sections changed to
have everything 64k aligned. Armv7 binaries built with this binutils version
run successfully on an arm64 system
On 04.12.14 22:15, Olof Johansson wrote:
On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf ag...@suse.de wrote:
With binutils 2.25 the default alignment for 32bit arm sections changed to
have everything 64k aligned. Armv7 binaries built with this binutils version
run successfully on an arm64
make sense to block people from enabling
CONFIG_COMPAT on those configurations.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- add comment in KConfig explaining that segments need to be 64k aligned
- conditionalize the option on EXPERT
---
arch/arm64/Kconfig | 6 +-
1 file
On 01.12.14 23:53, Stuart Yoder wrote:
>
>
>> -Original Message-----
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Thursday, November 27, 2014 10:14 AM
>> To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
>> linux-kernel
On 01.12.14 23:28, Stuart Yoder wrote:
>
>
>> -Original Message-----
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Thursday, November 27, 2014 8:30 AM
>> To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
>> linux-kernel@vger.k
On 01.12.14 23:28, Stuart Yoder wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, November 27, 2014 8:30 AM
To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
linux-kernel@vger.kernel.org
Cc: Yoder Stuart-B08248; Phillips Kim
On 01.12.14 23:53, Stuart Yoder wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, November 27, 2014 10:14 AM
To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
linux-kernel@vger.kernel.org
Cc: Yoder Stuart-B08248; Phillips
On 13.11.14 18:54, J. German Rivera wrote:
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
>
> Signed-off-by: J. German Rivera
> Signed-off-by: Stuart
On 13.11.14 18:54, J. German Rivera wrote:
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
>
> Signed-off-by: J. German Rivera
> Signed-off-by: Stuart
On 13.11.14 18:54, J. German Rivera wrote:
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera german.riv...@freescale.com
On 13.11.14 18:54, J. German Rivera wrote:
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera german.riv...@freescale.com
On 26.11.14 23:33, Stuart Yoder wrote:
>
>
>> -Original Message-----
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, November 26, 2014 4:16 AM
>> To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
>> linux-kernel
On 13.11.14 18:54, J. German Rivera wrote:
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
>
> Signed-off-by: J. German Rivera
> Signed-off-by: Stuart
On 13.11.14 18:54, J. German Rivera wrote:
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera german.riv...@freescale.com
On 26.11.14 23:33, Stuart Yoder wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, November 26, 2014 4:16 AM
To: Rivera Jose-B46482; gre...@linuxfoundation.org; a...@arndb.de;
linux-kernel@vger.kernel.org
Cc: Yoder Stuart-B08248; Phillips
On 13.11.14 18:54, J. German Rivera wrote:
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
>
> Signed-off-by: J. German Rivera
> Signed-off-by: Stuart
On 13.11.14 18:54, J. German Rivera wrote:
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera german.riv...@freescale.com
On 04.10.14 15:23, J. German Rivera wrote:
> From: "J. German Rivera"
>
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
>
> Signed-off-by: J. German
On 04.10.14 15:23, J. German Rivera wrote:
> From: "J. German Rivera"
>
> Platform device driver that sets up the basic bus infrastructure
> for the fsl-mc bus type, including support for adding/removing
> fsl-mc devices, register/unregister of fsl-mc drivers, and bus
> match support to bind
On 04.10.14 15:23, J. German Rivera wrote:
> From: "J. German Rivera"
>
> A DPRC (Data Path Resource Container) is an isolation device
> that contains a set of DPAA networking devices to be
> assigned to an isolation domain (e.g., a virtual machine).
>
> Signed-off-by: J. German Rivera
>
On 04.10.14 15:23, J. German Rivera wrote:
From: J. German Rivera german.riv...@freescale.com
Platform device driver that sets up the basic bus infrastructure
for the fsl-mc bus type, including support for adding/removing
fsl-mc devices, register/unregister of fsl-mc drivers, and bus
On 04.10.14 15:23, J. German Rivera wrote:
From: J. German Rivera german.riv...@freescale.com
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J.
On 04.10.14 15:23, J. German Rivera wrote:
From: J. German Rivera german.riv...@freescale.com
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
On 02.11.14 08:46, Matwey V. Kornilov wrote:
> I wish I knew. We need KBuild guru to ask how to take into account
> host architecture.
Hrm. At least this patch makes things more consistent with the other
Documentation makefiles:
Documentation/timers/Makefile:hostprogs-$(CONFIG_X86) :=
On 02.11.14 08:46, Matwey V. Kornilov wrote:
I wish I knew. We need KBuild guru to ask how to take into account
host architecture.
Hrm. At least this patch makes things more consistent with the other
Documentation makefiles:
Documentation/timers/Makefile:hostprogs-$(CONFIG_X86) :=
On 01.11.14 13:03, Matwey V. Kornilov wrote:
> 28.10.2014 16:12, Alexander Graf пишет:
>>
>>
>>
>>> Am 28.10.2014 um 13:47 schrieb Jonathan Corbet :
>>>
>>> On Mon, 27 Oct 2014 20:07:51 -0400
>>> Peter Foley wrote:
>>>
>>
On 01.11.14 13:03, Matwey V. Kornilov wrote:
28.10.2014 16:12, Alexander Graf пишет:
Am 28.10.2014 um 13:47 schrieb Jonathan Corbet cor...@lwn.net:
On Mon, 27 Oct 2014 20:07:51 -0400
Peter Foley pefol...@pefoley.com wrote:
The prctl test code in Documentation/ tries to show how to
use
> Am 28.10.2014 um 14:07 schrieb Suravee Suthikulanit
> :
>
>> On 10/27/2014 6:25 PM, Alexander Graf wrote:
>>
>>
>>> On 27.10.14 15:29, Suravee Suthikulanit wrote:
>>> On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>>>>> This
that other platforms don't try to call asm("rdtsc").
>>>
>>> Signed-off-by: Alexander Graf
>>
>> Acked-by: Peter Foley
>
> Snagged into the docs tree, thanks.
Awesome, please make sure this makes it into 3.18 - the build is broken on
non-x86 a
try to call asm(rdtsc).
Signed-off-by: Alexander Graf ag...@suse.de
Acked-by: Peter Foley pefol...@pefoley.com
Snagged into the docs tree, thanks.
Awesome, please make sure this makes it into 3.18 - the build is broken on
non-x86 archs there ;).
Alex
--
To unsubscribe from this list
Am 28.10.2014 um 14:07 schrieb Suravee Suthikulanit
suravee.suthikulpa...@amd.com:
On 10/27/2014 6:25 PM, Alexander Graf wrote:
On 27.10.14 15:29, Suravee Suthikulanit wrote:
On 10/26/2014 9:08 AM, Alexander Graf wrote:
This option doesn't exist in upstream kernels, does it? Why
The prctl test code in Documentation/ tries to show how to
use a call that only makes sense on x86. Restrict it there
so that other platforms don't try to call asm("rdtsc").
Signed-off-by: Alexander Graf
---
Documentation/prctl/Makefile | 2 +-
1 file changed, 1 insertion(+),
On 27.10.14 15:29, Suravee Suthikulanit wrote:
> On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>>> This option doesn't exist in upstream kernels, does it? Why not just
>>>> >>make it dtb-y?
>>> >
>>> >CONFIG_ARCH_SEATTLE is being added one
On 27.10.14 15:29, Suravee Suthikulanit wrote:
On 10/26/2014 9:08 AM, Alexander Graf wrote:
This option doesn't exist in upstream kernels, does it? Why not just
make it dtb-y?
CONFIG_ARCH_SEATTLE is being added one hunk above.:)
Oops:).
I'm not convinced we need a config option just
The prctl test code in Documentation/ tries to show how to
use a call that only makes sense on x86. Restrict it there
so that other platforms don't try to call asm(rdtsc).
Signed-off-by: Alexander Graf ag...@suse.de
---
Documentation/prctl/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
> Am 26.10.2014 um 13:43 schrieb Andreas Färber :
>
>> Am 26.10.2014 um 01:08 schrieb Alexander Graf:
>>> On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote:
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 48b7437..e4c052f 100644
Am 26.10.2014 um 13:43 schrieb Andreas Färber afaer...@suse.de:
Am 26.10.2014 um 01:08 schrieb Alexander Graf:
On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 48b7437..e4c052f 100644
--- a/arch/arm64/Kconfig
+++ b/arch
On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> Initial revision of device tree for AMD Seattle platform
>
> Cc: Mark Rutland
> Cc: Will Deacon
> Cc: Catalin Marinas
> Cc: Rob Herring
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Thomas
On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote:
From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
Initial revision of device tree for AMD Seattle platform
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Catalin Marinas catalin.mari...@arm.com
On 19.09.14 22:41, Scott Wood wrote:
> On Fri, 2014-09-19 at 22:32 +0200, Alexander Graf wrote:
>>
>> On 19.09.14 22:24, Kim Phillips wrote:
>>> On Fri, 19 Sep 2014 14:06:32 -0500
>>> Yoder Stuart-B08248 wrote:
>>>
>>>>>>>>>
On 19.09.14 22:24, Kim Phillips wrote:
> On Fri, 19 Sep 2014 14:06:32 -0500
> Yoder Stuart-B08248 wrote:
>
> +/**
> + * @briefManagement Complex firmware version information
> + */
> +#define MC_VER_MAJOR 2
> +#define MC_VER_MINOR 0
On 19.09.14 22:24, Kim Phillips wrote:
On Fri, 19 Sep 2014 14:06:32 -0500
Yoder Stuart-B08248 stuart.yo...@freescale.com wrote:
+/**
+ * @briefManagement Complex firmware version information
+ */
+#define MC_VER_MAJOR 2
+#define MC_VER_MINOR 0
code should be adjusted to run on all
On 19.09.14 22:41, Scott Wood wrote:
On Fri, 2014-09-19 at 22:32 +0200, Alexander Graf wrote:
On 19.09.14 22:24, Kim Phillips wrote:
On Fri, 19 Sep 2014 14:06:32 -0500
Yoder Stuart-B08248 stuart.yo...@freescale.com wrote:
+/**
+ * @briefManagement Complex firmware version information
> Am 18.09.2014 um 06:17 schrieb German Rivera :
>
>> On 09/15/2014 06:44 PM, Kim Phillips wrote:
>> On Thu, 11 Sep 2014 12:34:21 -0500
>> "J. German Rivera" wrote:
>>
>>> From: "J. German Rivera"
>>>
>>> APIs to access the Management Complex (MC) hardware
>>> module of Freescale LS2 SoCs.
> Am 18.09.2014 um 02:20 schrieb German Rivera :
>
>> On 09/15/2014 06:44 PM, Kim Phillips wrote:
>> On Thu, 11 Sep 2014 12:34:20 -0500
>> "J. German Rivera" wrote:
>>
>>> This patch series introduces Linux support for the Freescale
>>> Management Complex (fsl-mc) hardware.
>>
>> here are
Am 18.09.2014 um 02:20 schrieb German Rivera german.riv...@freescale.com:
On 09/15/2014 06:44 PM, Kim Phillips wrote:
On Thu, 11 Sep 2014 12:34:20 -0500
J. German Rivera german.riv...@freescale.com wrote:
This patch series introduces Linux support for the Freescale
Management Complex
Am 18.09.2014 um 06:17 schrieb German Rivera german.riv...@freescale.com:
On 09/15/2014 06:44 PM, Kim Phillips wrote:
On Thu, 11 Sep 2014 12:34:21 -0500
J. German Rivera german.riv...@freescale.com wrote:
From: J. German Rivera german.riv...@freescale.com
APIs to access the
when preparing the first patch.
>
>
> Radim Krčmář (2):
> KVM: static inline empty kvm_arch functions
> KVM: remove garbage arg to *hardware_{en,dis}able
Acked-by: Alexander Graf
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
the first patch.
Radim Krčmář (2):
KVM: static inline empty kvm_arch functions
KVM: remove garbage arg to *hardware_{en,dis}able
Acked-by: Alexander Graf ag...@suse.de
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
().
This replaces get_order() with order_base_2() (round-up version of ilog2).
Suggested-by: Paul Mackerras
Cc: Alexander Graf
Cc: Aneesh Kumar K.V
Cc: Joonsoo Kim
Cc: Benjamin Herrenschmidt
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Aneesh Kumar K.V
So this affects 3.17?
Alex
on VM_BUG_ON().
This replaces get_order() with order_base_2() (round-up version of ilog2).
Suggested-by: Paul Mackerras pau...@samba.org
Cc: Alexander Graf ag...@suse.de
Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Benjamin Herrenschmidt b
On 26.06.14 01:59, Alexey Kardashevskiy wrote:
On 06/26/2014 07:12 AM, Alexander Graf wrote:
On 06.06.14 02:20, Alexey Kardashevskiy wrote:
On 06/05/2014 09:57 PM, Alexander Graf wrote:
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements
On 26.06.14 01:59, Alexey Kardashevskiy wrote:
On 06/26/2014 07:12 AM, Alexander Graf wrote:
On 06.06.14 02:20, Alexey Kardashevskiy wrote:
On 06/05/2014 09:57 PM, Alexander Graf wrote:
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements
On 06.06.14 02:20, Alexey Kardashevskiy wrote:
On 06/05/2014 09:57 PM, Alexander Graf wrote:
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed
On 06.06.14 02:20, Alexey Kardashevskiy wrote:
On 06/05/2014 09:57 PM, Alexander Graf wrote:
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (64<<30)/(16<<20)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (6430)/(1620)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
Signed-off-by: Kim Phillips
Looks largely identical to the PCI version of the same that has been
accepted for v3.16 and ack'd by GregKH.
Reviewed-by: Alex Williamson
Yup, would be great to have feature parity for device binding on
platform and PCI.
Reviewed-by: Alexander Graf
Alex
--
for device binding on
platform and PCI.
Reviewed-by: Alexander Graf ag...@suse.de
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On 22.05.14 22:36, Christian Borntraeger wrote:
On 22/05/14 10:53, Paolo Bonzini wrote:
Il 22/05/2014 10:23, Michael Mueller ha scritto:
On Wed, 21 May 2014 15:22:35 +0200
Alexander Graf wrote:
I have seen the slides from Eduardo which he presented during this years
DevConf in Brno and made
On 22.05.14 22:36, Christian Borntraeger wrote:
On 22/05/14 10:53, Paolo Bonzini wrote:
Il 22/05/2014 10:23, Michael Mueller ha scritto:
On Wed, 21 May 2014 15:22:35 +0200
Alexander Graf ag...@suse.de wrote:
I have seen the slides from Eduardo which he presented during this years
DevConf
On 21.05.14 14:56, Michael Mueller wrote:
On Tue, 20 May 2014 12:10:23 +0200
Alexander Graf wrote:
On 20.05.14 12:02, Michael Mueller wrote:
On Mon, 19 May 2014 22:14:00 +0200
Alexander Graf wrote:
On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014 16:49:28 +0200
Alexander
driver
matches.
Signed-off-by: Alex Williamson
Cc: Greg Kroah-Hartman
Reviewed-by: Alexander Graf
I suppose Konrad's RB stays as well?
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
Williamson alex.william...@redhat.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Reviewed-by: Alexander Graf ag...@suse.de
I suppose Konrad's RB stays as well?
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 21.05.14 14:56, Michael Mueller wrote:
On Tue, 20 May 2014 12:10:23 +0200
Alexander Graf ag...@suse.de wrote:
On 20.05.14 12:02, Michael Mueller wrote:
On Mon, 19 May 2014 22:14:00 +0200
Alexander Graf ag...@suse.de wrote:
On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014
On 20.05.14 12:02, Michael Mueller wrote:
On Mon, 19 May 2014 22:14:00 +0200
Alexander Graf wrote:
On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014 16:49:28 +0200
Alexander Graf wrote:
[...]
What user and thus also user space wants depends on other factors:
1
On 20.05.14 12:02, Michael Mueller wrote:
On Mon, 19 May 2014 22:14:00 +0200
Alexander Graf ag...@suse.de wrote:
On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014 16:49:28 +0200
Alexander Graf ag...@suse.de wrote:
[...]
What user and thus also user space wants depends
On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014 16:49:28 +0200
Alexander Graf wrote:
On 19.05.14 16:18, Michael Mueller wrote:
On Mon, 19 May 2014 13:48:08 +0200
Alexander Graf wrote:
On 19.05.14 12:53, Michael Mueller wrote:
On Fri, 16 May 2014 22:31:12 +0200
Alexander
On 19.05.14 16:18, Michael Mueller wrote:
On Mon, 19 May 2014 13:48:08 +0200
Alexander Graf wrote:
On 19.05.14 12:53, Michael Mueller wrote:
On Fri, 16 May 2014 22:31:12 +0200
Alexander Graf wrote:
On 16.05.14 17:39, Michael Mueller wrote:
On Fri, 16 May 2014 14:08:24 +0200
Alexander
t pci_dev *pdev = to_pci_dev(dev);
+ char *driver_override, *old = pdev->driver_override, *cp;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
Is there anything we have to do on hot remove of this device to free
t
501 - 600 of 847 matches
Mail list logo
