Commit-ID: 50849eefea3ba8aa6e540e0cbdc9533098f25656
Gitweb: http://git.kernel.org/tip/50849eefea3ba8aa6e540e0cbdc9533098f25656
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Thu, 5 Feb 2015 15:31:56 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 18 Feb 2015 22:10:54
Commit-ID: e0fd24a3b4ad7b4084b41944835952eedec53f98
Gitweb: http://git.kernel.org/tip/e0fd24a3b4ad7b4084b41944835952eedec53f98
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Thu, 5 Feb 2015 15:39:34 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 18 Feb 2015 22:08:46
>>> On 17.02.15 at 07:51, wrote:
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> it if 0 is given (See
On 17.02.15 at 07:51, xiaoming.w...@intel.com wrote:
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
it if 0 is given (See
fectly fine to add it.
Jan
> ---
> Subject: sched/numa: Avoid some pointless iterations
> From: Jan Beulich
> Date: Mon Feb 9 12:30:00 CET 2015
>
> Commit 81907478c431 ("sched/fair: Avoid using uninitialized variable
> in preferred_group_nid()") unconditional
it.
Jan
---
Subject: sched/numa: Avoid some pointless iterations
From: Jan Beulich jbeul...@suse.com
Date: Mon Feb 9 12:30:00 CET 2015
Commit 81907478c431 (sched/fair: Avoid using uninitialized variable
in preferred_group_nid()) unconditionally initializes max_group with
NODE_MASK_NONE
an incremental update of the configuration (make oldconfig).
Signed-off-by: Jan Beulich
---
arch/x86/Kconfig | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- 3.19-rc7/arch/x86/Kconfig
+++ 3.19-rc7-x86-Kconfig-cleanup/arch/x86/Kconfig
@@ -232,12 +232,10 @@ config
Since dependencies are transitive, we don't really need to repeat those
of X86_UP_IOAPIC.
Furthermore avoid the symbol getting entered into .config when it is
off by having the default simply Y and the dependencies solely handled
via the intended for that purpose "depends on".
Signed-o
We don't really need a helper symbol for that. For one, it's
pointlessly getting set to Y for all configurations (even 64-bit ones).
And then the purpose can be fulfilled by suitably adjusting
X86_UP_APIC: Hide its prompt when PCI_MSI, and default it to PCI_MSI.
Signed-off-by: Jan Beulich
Cc
an incremental update of the configuration (make oldconfig).
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/Kconfig | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- 3.19-rc7/arch/x86/Kconfig
+++ 3.19-rc7-x86-Kconfig-cleanup/arch/x86/Kconfig
@@ -232,12 +232,10 @@ config
We don't really need a helper symbol for that. For one, it's
pointlessly getting set to Y for all configurations (even 64-bit ones).
And then the purpose can be fulfilled by suitably adjusting
X86_UP_APIC: Hide its prompt when PCI_MSI, and default it to PCI_MSI.
Signed-off-by: Jan Beulich jbeul
Since dependencies are transitive, we don't really need to repeat those
of X86_UP_IOAPIC.
Furthermore avoid the symbol getting entered into .config when it is
off by having the default simply Y and the dependencies solely handled
via the intended for that purpose depends on.
Signed-off-by: Jan
>>> On 03.02.15 at 22:03, wrote:
> On Wed, 2015-02-04 at 07:50 +1100, NeilBrown wrote:
>> Actually the prefix of this macro is "CONFIG_AS_", not "CONFIG_" :-)
>> CONFIG_AS_ is reserved for assembly magic, and is never used by the the
>> kconfig system.
>>
>> (Well. I might have made bits of
On 03.02.15 at 22:03, pebo...@tiscali.nl wrote:
On Wed, 2015-02-04 at 07:50 +1100, NeilBrown wrote:
Actually the prefix of this macro is CONFIG_AS_, not CONFIG_ :-)
CONFIG_AS_ is reserved for assembly magic, and is never used by the the
kconfig system.
(Well. I might have made bits of
>>> On 30.01.15 at 12:21, wrote:
> @@ -734,11 +734,11 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
> if (!pending_req)
> return 1;
>
> - ring_req = RING_GET_REQUEST(ring, rc);
> + memcpy(_req, RING_GET_REQUEST(ring, rc),
On 30.01.15 at 12:21, jgr...@suse.com wrote:
@@ -734,11 +734,11 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
if (!pending_req)
return 1;
- ring_req = RING_GET_REQUEST(ring, rc);
+ memcpy(ring_req,
Commit-ID: 81907478c4311a679849216abf723999184ab984
Gitweb: http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:25:38 +
Committer: Ingo Molnar
CommitDate: Wed, 28 Jan 2015 13:14:12 +0100
sched/fair: Avoid using
>>> On 28.01.15 at 15:29, wrote:
> Commit-ID: 81907478c4311a679849216abf723999184ab984
> Gitweb:
> http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
> Author: Jan Beulich
> AuthorDate: Fri, 23 Jan 2015 08:25:38 +
> Committer: Ingo Mo
Commit-ID: 81907478c4311a679849216abf723999184ab984
Gitweb: http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 23 Jan 2015 08:25:38 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 28 Jan 2015 13:14:12
On 28.01.15 at 15:29, tip...@zytor.com wrote:
Commit-ID: 81907478c4311a679849216abf723999184ab984
Gitweb:
http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 23 Jan 2015 08:25:38 +
Committer: Ingo Molnar
>>> On 27.01.15 at 02:51, wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
approach for upstream. If 32-bit ones are to become deliberately
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
approach for upstream. If 32-bit ones are to
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + *
On 23.01.15 at 19:58, mcg...@suse.com wrote:
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
@@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
set_irq_regs(old_regs);
}
+/*
+ * CONFIG_PREEMPT=n
>>> On 23.01.15 at 10:58, wrote:
> On Fri, Jan 23, 2015 at 08:32:01AM +, Jan Beulich wrote:
>> The compiler validly warns about it being ignored.
>>
>> Signed-off-by: Jan Beulich
>
> Applied, thanks.
>
> Out of curiosity: When do you see
>>> On 23.01.15 at 10:54, wrote:
> On Fri, Jan 23, 2015 at 08:25:38AM +, Jan Beulich wrote:
>> At least some gcc versions - validly afaict - warn about potentially
>> using max_group uninitialized: There's no way the compiler can prove
>> that the
As a module_init() function, this should have been this way from the
beginning.
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/drivers/xen/tmem.c
+++ 3.19-rc5-xen-tmem-init/drivers/xen/tmem.c
@@ -374,7 +374,7 @@ static
Not just setting it when the feature is available is for consistency,
and may allow Xen to drop its custom clearing of the flag (unless it
needs it cleared earlier than this code executes). Note that the change
is benign to ix86, as the flag starts out clear there.
Signed-off-by: Jan Beulich
The compiler validly warns about it being ignored.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ 3.19-rc5-x86-MCE-AMD-bank4_names/arch/x86/kernel/cpu/mcheck
Just like for AVX2 (which simply needs an #if -> #ifdef conversion),
SSSE3 assembler support should be checked for before using it.
Signed-off-by: Jan Beulich
Cc: Jim Kukunas
Cc: Neil Brown
---
arch/x86/Makefile |1 +
lib/raid6/algos.c |2 +-
lib/raid6/recov_avx2.c |
the
outer loop when max_faults is still zero after the inner loop. For the
compiler's sake, mark max_group uninitialized, as we're now able to
prove it's not actually being used uninitalized anymore.
Signed-off-by: Jan Beulich
Cc: Rik van Riel
---
kernel/sched/fair.c |4 +++-
1 file changed
There not being a similar difference in page fault handling, I can't
see why 32- and 64-bit should differ in behavior here.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/traps.c |2 --
1 file changed, 2 deletions(-)
--- 3.19-rc5/arch/x86/kernel/traps.c
+++ 3.19-rc5-ix86-show-unhandled
the
outer loop when max_faults is still zero after the inner loop. For the
compiler's sake, mark max_group uninitialized, as we're now able to
prove it's not actually being used uninitalized anymore.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Rik van Riel r...@redhat.com
---
kernel/sched
As a module_init() function, this should have been this way from the
beginning.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/drivers/xen/tmem.c
+++ 3.19-rc5-xen-tmem-init/drivers/xen/tmem.c
@@ -374,7
The compiler validly warns about it being ignored.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ 3.19-rc5-x86-MCE-AMD-bank4_names/arch/x86
Not just setting it when the feature is available is for consistency,
and may allow Xen to drop its custom clearing of the flag (unless it
needs it cleared earlier than this code executes). Note that the change
is benign to ix86, as the flag starts out clear there.
Signed-off-by: Jan Beulich
Just like for AVX2 (which simply needs an #if - #ifdef conversion),
SSSE3 assembler support should be checked for before using it.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Jim Kukunas james.t.kuku...@linux.intel.com
Cc: Neil Brown ne...@suse.de
---
arch/x86/Makefile |1 +
lib
There not being a similar difference in page fault handling, I can't
see why 32- and 64-bit should differ in behavior here.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/kernel/traps.c |2 --
1 file changed, 2 deletions(-)
--- 3.19-rc5/arch/x86/kernel/traps.c
+++ 3.19-rc5-ix86
On 23.01.15 at 10:54, pet...@infradead.org wrote:
On Fri, Jan 23, 2015 at 08:25:38AM +, Jan Beulich wrote:
At least some gcc versions - validly afaict - warn about potentially
using max_group uninitialized: There's no way the compiler can prove
that the body of the conditional where
On 23.01.15 at 10:58, b...@alien8.de wrote:
On Fri, Jan 23, 2015 at 08:32:01AM +, Jan Beulich wrote:
The compiler validly warns about it being ignored.
Signed-off-by: Jan Beulich jbeul...@suse.com
Applied, thanks.
Out of curiosity: When do you see this? Building with
-Wignored
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch.
Signed-off-by: Jan Beulich
---
v2: Deal with architectures not defining raw_irqs_disabled() by
retaining the CONFIG_TRACE_IRQFLAGS_SUPPORT-dependent
Commit-ID: 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Gitweb: http://git.kernel.org/tip/4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Author: Jan Beulich
AuthorDate: Fri, 16 Jan 2015 15:47:07 +
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jan 2015 12:37:23 +0100
x86, irq: Properly tag
Commit-ID: 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Gitweb: http://git.kernel.org/tip/4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 16 Jan 2015 15:47:07 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 20 Jan 2015 12
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
v2: Deal with architectures not defining raw_irqs_disabled() by
retaining
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc4/arch/x86/kernel/irq.c
+++ 3.19-rc4-xen-x86-HYP-interrupt/arch/x86/kernel/irq.c
@@ -127,7 +127,7 @@ int
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc4/arch/x86/kernel/irq.c
+++ 3.19-rc4-xen-x86-HYP-interrupt/arch/x86/kernel/irq.c
@@ -127,7 +127,7 @@ int
>>> On 13.01.15 at 14:29, wrote:
> Em Tue, Jan 13, 2015 at 08:48:35AM +, Jan Beulich escreveu:
>> Arnaldo,
>>
>> considering that tools/include/ gets used by other than just perf, in
>> particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
>
Arnaldo,
considering that tools/include/ gets used by other than just perf, in
particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
"tools: Move bitops.h from tools/perf/util to tools/" adding an
inclusion of asm/hweight.h to linux/bitops.h is supposed to work,
when the only
Arnaldo,
considering that tools/include/ gets used by other than just perf, in
particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
tools: Move bitops.h from tools/perf/util to tools/ adding an
inclusion of asm/hweight.h to linux/bitops.h is supposed to work,
when the only potentially
On 13.01.15 at 14:29, a...@redhat.com wrote:
Em Tue, Jan 13, 2015 at 08:48:35AM +, Jan Beulich escreveu:
Arnaldo,
considering that tools/include/ gets used by other than just perf, in
particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
tools: Move bitops.h from tools/perf
the time. Note
further that hardware NMI handling for PVH doesn't currently work
anyway due to missing code in the hypervisor (but it is expected to
work the native rather than the PV way).
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v2: Use DEFINE_GUEST_HANDLE_STRUCT() instead
the time. Note
further that hardware NMI handling for PVH doesn't currently work
anyway due to missing code in the hypervisor (but it is expected to
work the native rather than the PV way).
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
v2
>>> On 09.01.15 at 13:51, wrote:
> On 09/01/15 09:57, Jan Beulich wrote:
>>>>> On 08.01.15 at 18:01, wrote:
>>> @@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long
>>> pfn, unsigned long mfn)
>>> }
>&
>>> On 08.01.15 at 18:01, wrote:
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size)
> unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
> {
> int i;
> - unsigned long addr = PFN_PHYS(pfn);
>
On 08.01.15 at 18:01, jgr...@suse.com wrote:
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size)
unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
{
int i;
- unsigned long addr =
On 09.01.15 at 13:51, david.vra...@citrix.com wrote:
On 09/01/15 09:57, Jan Beulich wrote:
On 08.01.15 at 18:01, jgr...@suse.com wrote:
@@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long
pfn, unsigned long mfn)
}
/* Update kernel mapping
>>> On 07.01.15 at 17:30, wrote:
> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>> be used) instead of the Xen clocksource should not cause any issues, as
>> Dom0 VMs never
On 07.01.15 at 17:30, ian.campb...@citrix.com wrote:
On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
In Dom0's the use of the TSC clocksource (whenever it is stable enough to
be used) instead of the Xen clocksource should not cause any issues, as
Dom0
>>> David Vrabel 01/05/15 11:35 AM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
David Vrabel david.vra...@citrix.com 01/05/15 11:35 AM
On 19/12/14 16:16, Jan Beulich wrote:
Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info
>>> Andy Lutomirski 01/02/15 7:03 PM >>>
>On Jan 2, 2015 8:11 AM, "Jan Beulich" wrote:
>> Trying to guess what you mean by "this": A stack switch gets expressed by
>> CFI annotations just like any other frame pointer adjustments
Andy Lutomirski l...@amacapital.net 01/02/15 7:03 PM
On Jan 2, 2015 8:11 AM, Jan Beulich jbeul...@suse.com wrote:
Trying to guess what you mean by this: A stack switch gets expressed by
CFI annotations just like any other frame pointer adjustments. See for
example
the CFI_DEF_CFA_REGISTER
on -> NMI, then
>task_pt_regs is entirely uninitialized. Assuming all the CFI
>annotations are correct, the unwinder could still do it from the
>kernel.
>
>Note that, as far as I know, Jan Beulich is the only person who uses
>the unwinder on kernel code. Jan, how do you do this
>>> David Vrabel 12/23/14 12:01 PM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
could still do it from the
kernel.
Note that, as far as I know, Jan Beulich is the only person who uses
the unwinder on kernel code. Jan, how do you do this?
Trying to guess what you mean by this: A stack switch gets expressed by
CFI annotations just like any other frame pointer adjustments. See
David Vrabel david.vra...@citrix.com 12/23/14 12:01 PM
On 19/12/14 16:16, Jan Beulich wrote:
Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info
Commit-ID: 132978b94e66f8ad7d20790f8332f0e9c1426029
Gitweb: http://git.kernel.org/tip/132978b94e66f8ad7d20790f8332f0e9c1426029
Author: Jan Beulich
AuthorDate: Fri, 19 Dec 2014 16:10:54 +
Committer: Ingo Molnar
CommitDate: Tue, 23 Dec 2014 11:39:34 +0100
x86: Fix step size
Commit-ID: 132978b94e66f8ad7d20790f8332f0e9c1426029
Gitweb: http://git.kernel.org/tip/132978b94e66f8ad7d20790f8332f0e9c1426029
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 19 Dec 2014 16:10:54 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 23 Dec 2014 11:39:34
can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Signed-off-by: Jan Beulich
---
arch/x86/xen/enlighten.c| 22 +-
include/xen/interface/nmi.h
n't really work well.
Signed-off-by: Jan Beulich
Cc: Yinghai Lu
---
arch/x86/mm/init.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
--- 3.18/arch/x86/mm/init.c
+++ 3.18-x86-init-mem-steps/arch/x86/mm/init.c
@@ -409,20 +409,20 @@ static unsigned l
Commit-ID: 2414e021ac8d588f1b09f64891f69a3e26feadf1
Gitweb: http://git.kernel.org/tip/2414e021ac8d588f1b09f64891f69a3e26feadf1
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner
CommitDate: Tue, 16 Dec 2014 14:08:14 +0100
x86: Avoid building
Commit-ID: e10679825924580845c4825deaaddf5331ff627c
Gitweb: http://git.kernel.org/tip/e10679825924580845c4825deaaddf5331ff627c
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 16 Dec 2014 14:08:14 +0100
x86: irq: Fix placement
Commit-ID: e10679825924580845c4825deaaddf5331ff627c
Gitweb: http://git.kernel.org/tip/e10679825924580845c4825deaaddf5331ff627c
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 16 Dec 2014 14:08
Commit-ID: 2414e021ac8d588f1b09f64891f69a3e26feadf1
Gitweb: http://git.kernel.org/tip/2414e021ac8d588f1b09f64891f69a3e26feadf1
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 16 Dec 2014 14:08
really work well.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Yinghai Lu ying...@kernel.org
---
arch/x86/mm/init.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
--- 3.18/arch/x86/mm/init.c
+++ 3.18-x86-init-mem-steps/arch/x86/mm/init.c
@@ -409,20
can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/xen/enlighten.c| 22 +-
include/xen
>>> On 15.12.14 at 12:38, wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
>
> Why are these changes here and not in arch/x86/xen/Makefile?
Because this needs to be done in a step that (afaict) has no hook
in the
>>> On 12.12.14 at 23:48, wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>>
On 12.12.14 at 23:48, boris.ostrov...@oracle.com wrote:
On 12/11/2014 01:04 PM, Juergen Gross wrote:
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
On 15.12.14 at 12:38, david.vra...@citrix.com wrote:
On 11/12/14 18:04, Juergen Gross wrote:
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
Why are these changes here and not in arch/x86/xen/Makefile?
Because this needs to be done in a step that (afaict) has no hook
in
>>> On 11.12.14 at 00:34, wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> }
> EXPORT_SYMBOL(_cond_resched);
>
> +int __sched cond_resched_irq(void)
> +{
> + if (should_resched()) {
> +
On 11.12.14 at 00:34, mcg...@do-not-panic.com wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
}
EXPORT_SYMBOL(_cond_resched);
+int __sched cond_resched_irq(void)
+{
+ if (should_resched()) {
+
>>> On 04.12.14 at 12:07, wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich
>>
>> When a PF driver unloads, it may find it necessary to leave the VFs
>> around simply because of pciback having marked them as assigned to a
>&
On 04.12.14 at 12:07, david.vra...@citrix.com wrote:
On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
From: Jan Beulich jbeul...@suse.com
When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize
>>> Konrad Rzeszutek Wilk 12/02/14 4:05 PM >>>
>On Tue, Dec 02, 2014 at 10:10:11AM +, Jan Beulich wrote:
>> >>> On 21.11.14 at 23:17, wrote:
>> > Konrad Rzeszutek Wilk (7):
>> > xen/pciback: Don't deadlock when unbinding.
>&
>>> On 21.11.14 at 23:17, wrote:
> Konrad Rzeszutek Wilk (7):
> xen/pciback: Don't deadlock when unbinding.
> driver core: Provide an wrapper around the mutex to do lockdep warnings
> xen/pciback: Include the domain id if removing the device whilst still
> in use
>
On 21.11.14 at 23:17, konrad.w...@oracle.com wrote:
Konrad Rzeszutek Wilk (7):
xen/pciback: Don't deadlock when unbinding.
driver core: Provide an wrapper around the mutex to do lockdep warnings
xen/pciback: Include the domain id if removing the device whilst still
in use
Konrad Rzeszutek Wilk konrad.w...@oracle.com 12/02/14 4:05 PM
On Tue, Dec 02, 2014 at 10:10:11AM +, Jan Beulich wrote:
On 21.11.14 at 23:17, konrad.w...@oracle.com wrote:
Konrad Rzeszutek Wilk (7):
xen/pciback: Don't deadlock when unbinding.
driver core: Provide
>>> On 10.11.14 at 13:13, wrote:
> * Jan Beulich wrote:
>> @@ -131,7 +131,7 @@
>> } while (0)
>>
>>
>> -#else /* !CONFIG_TRACE_IRQFLAGS_SUPPORT */
>> +#else /* !CONFIG_TRACE_IRQFLAGS */
>>
>> #define local_irq_en
On 10.11.14 at 13:13, mi...@kernel.org wrote:
* Jan Beulich jbeul...@suse.com wrote:
@@ -131,7 +131,7 @@
} while (0)
-#else /* !CONFIG_TRACE_IRQFLAGS_SUPPORT */
+#else /* !CONFIG_TRACE_IRQFLAGS */
#define local_irq_enable() do { raw_local_irq_enable(); } while (0)
#define
>>> On 21.11.14 at 23:03, wrote:
> I rewrote it a bit to be more in the style of pciback:
>[...]
> [v2: Removed the switch statement, moved it about]
What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I suppose
normally will)
On 21.11.14 at 23:03, konrad.w...@oracle.com wrote:
I rewrote it a bit to be more in the style of pciback:
[...]
[v2: Removed the switch statement, moved it about]
What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I
; Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
>
> Signed-off-by: David Vrabel
Reviewed-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
that uses the maximum MFN to calculate
the DMA mask.
Signed-off-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Jan Beulich jbeul...@suse.com
--
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
>>> On 13.11.14 at 11:38, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>>
>>> On 13.11.14 at 11:25, wrote:
On 12.11.14 at 16:25, wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>> struct pdev_archdata {
>> };
>>
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
>
> Is there a particular
>>> On 12.11.14 at 16:25, wrote:
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
> struct pdev_archdata {
> };
>
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather than in
>>> On 12.11.14 at 16:55, wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) +
On 12.11.14 at 16:55, jbeul...@suse.com wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+u64 max_mfn;
+
+max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+return DMA_BIT_MASK(fls64(max_mfn
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather
801 - 900 of 2685 matches
Mail list logo
