>>> On 16.06.15 at 21:10, wrote:
> Append 0x to all %x in order to avoid while reading when there is other
> decimal value in the log.
To save on the space taken by the format strings you should prefer
%#x over 0x%x (like we do in the hypervisor).
Jan
--
To unsubscribe from this list: send the
On 16.06.15 at 21:10, julien.gr...@citrix.com wrote:
Append 0x to all %x in order to avoid while reading when there is other
decimal value in the log.
To save on the space taken by the format strings you should prefer
%#x over 0x%x (like we do in the hypervisor).
Jan
--
To unsubscribe from
Signed-off-by: Jan Beulich
---
v3: Split off from main patch.
--- a/scripts/kconfig/zconf.lex.c_shipped
+++ b/scripts/kconfig/zconf.lex.c_shipped
@@ -365,333 +365,354 @@ int zconflineno = 1;
extern char *zconftext;
#define yytext_ptr zconftext
-static yyconst flex_int16_t yy_nxt[][17
now works as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.
Signed-off-by: Jan Beulich
---
v3: Split changes to generated files from main patch to a subsequent
one.
--- a/scri
1: allow use of relations other than (in)equality
2: re-generate *.c_shipped files after previous change
Signed-off-by: Jan Beulich
---
Note that while benign for the first patch, the second patch can only
be applied cleanly on top of "kconfig: don't silently ignore unhandled
characters&quo
>>> On 13.06.15 at 01:15, wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote:
>>
>> >>> On 12.06.15 at 01:23, wrote:
>> > There are two usages on MTRRs:
>> > 1) MTRR entries set by firmware
>> > 2) MTRR entries set by
Signed-off-by: Jan Beulich jbeul...@suse.com
---
v3: Split off from main patch.
--- a/scripts/kconfig/zconf.lex.c_shipped
+++ b/scripts/kconfig/zconf.lex.c_shipped
@@ -365,333 +365,354 @@ int zconflineno = 1;
extern char *zconftext;
#define yytext_ptr zconftext
-static yyconst flex_int16_t
as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
v3: Split changes to generated files from main patch to a subsequent
one
1: allow use of relations other than (in)equality
2: re-generate *.c_shipped files after previous change
Signed-off-by: Jan Beulich jbeul...@suse.com
---
Note that while benign for the first patch, the second patch can only
be applied cleanly on top of kconfig: don't silently ignore unhandled
On 13.06.15 at 01:15, l...@amacapital.net wrote:
On Jun 12, 2015 12:59 AM, Jan Beulich jbeul...@suse.com wrote:
On 12.06.15 at 01:23, toshi.k...@hp.com wrote:
There are two usages on MTRRs:
1) MTRR entries set by firmware
2) MTRR entries set by OS drivers
We can obsolete 2
>>> On 12.06.15 at 01:23, wrote:
> There are two usages on MTRRs:
> 1) MTRR entries set by firmware
> 2) MTRR entries set by OS drivers
>
> We can obsolete 2), but we have no control over 1). As UEFI firmwares
> also set this up, this usage will continue to stay. So, we should not
> get rid
On 12.06.15 at 01:23, toshi.k...@hp.com wrote:
There are two usages on MTRRs:
1) MTRR entries set by firmware
2) MTRR entries set by OS drivers
We can obsolete 2), but we have no control over 1). As UEFI firmwares
also set this up, this usage will continue to stay. So, we should not
Commit-ID: 2f63b9db7260beba3c19d66d6c11b0b78ea84a8c
Gitweb: http://git.kernel.org/tip/2f63b9db7260beba3c19d66d6c11b0b78ea84a8c
Author: Jan Beulich
AuthorDate: Mon, 1 Jun 2015 13:03:59 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Jun 2015 10:10:09 +0200
x86/asm/entry/64: Fold
Commit-ID: 2bf557ea3f49576fabe24cd5daf1a34e9ee22c3c
Gitweb: http://git.kernel.org/tip/2bf557ea3f49576fabe24cd5daf1a34e9ee22c3c
Author: Jan Beulich
AuthorDate: Mon, 1 Jun 2015 13:02:55 +0100
Committer: Ingo Molnar
CommitDate: Tue, 2 Jun 2015 10:10:09 +0200
x86/asm/entry/64: Use
Commit-ID: 2bf557ea3f49576fabe24cd5daf1a34e9ee22c3c
Gitweb: http://git.kernel.org/tip/2bf557ea3f49576fabe24cd5daf1a34e9ee22c3c
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 1 Jun 2015 13:02:55 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 2 Jun 2015 10:10:09
Commit-ID: 2f63b9db7260beba3c19d66d6c11b0b78ea84a8c
Gitweb: http://git.kernel.org/tip/2f63b9db7260beba3c19d66d6c11b0b78ea84a8c
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 1 Jun 2015 13:03:59 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 2 Jun 2015 10:10:09
retint_kernel doesn't require %rcx to be pointing to thread info
(anymore?), and the code on the two alternative paths is - not really
surprisingly - identical.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
---
arch/x86/kernel/entry_64.S | 10 ++
1 file changed, 2 insertions(+), 8
Doing so allows adjustments by 128 bytes (occurring for
REMOVE_PT_GPREGS_FROM_STACK 8 uses) to be expressed with a single byte
immediate.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/calling.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc6/arch/x86/include/asm
retint_kernel doesn't require %rcx to be pointing to thread info
(anymore?), and the code on the two alternative paths is - not really
surprisingly - identical.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Andy Lutomirski l...@kernel.org
---
arch/x86/kernel/entry_64.S | 10 ++
1
Doing so allows adjustments by 128 bytes (occurring for
REMOVE_PT_GPREGS_FROM_STACK 8 uses) to be expressed with a single byte
immediate.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/include/asm/calling.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc6/arch
Commit-ID: 7ba554b5ac69e5f3edac9ce3233beb5acd480878
Gitweb: http://git.kernel.org/tip/7ba554b5ac69e5f3edac9ce3233beb5acd480878
Author: Jan Beulich
AuthorDate: Thu, 28 May 2015 09:16:45 +0100
Committer: Ingo Molnar
CommitDate: Fri, 29 May 2015 09:46:40 +0200
x86/asm/entry/32: Really
Commit-ID: 7ba554b5ac69e5f3edac9ce3233beb5acd480878
Gitweb: http://git.kernel.org/tip/7ba554b5ac69e5f3edac9ce3233beb5acd480878
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Thu, 28 May 2015 09:16:45 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 29 May 2015 09:46:40
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
v2: Drop the description at David's request.
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int __init xen_tmem_init(void
>>> On 28.05.15 at 13:20, wrote:
> * Jan Beulich wrote:
>> Not sure why assembly code should look like C code. It's a matter of taste
>> perhaps, and I can see your point, but I'm also not really eager to do
> changes
>> just to match other people's taste
>>> On 28.05.15 at 12:36, wrote:
> On 28/05/15 09:23, Jan Beulich wrote:
>> ... when the checked expression is compile time constant.
>
> Commit messages should be complete sentences, please.
Do you mean I should repeat the start of the sentence from the
>>> On 28.05.15 at 11:01, wrote:
> * Jan Beulich wrote:
>> --- 4.1-rc5/arch/x86/kernel/entry_64.S
>> +++ 4.1-rc5-x86_64-unwind-info/arch/x86/kernel/entry_64.S
>> @@ -148,7 +148,7 @@ ENDPROC(native_usergs_sysret64)
>> /*
>> * frame that enables
Commit-ID: 1e6277de3a23373b89e0affc3d179f2173b857a4
Gitweb: http://git.kernel.org/tip/1e6277de3a23373b89e0affc3d179f2173b857a4
Author: Jan Beulich
AuthorDate: Thu, 28 May 2015 09:29:27 +0100
Committer: Ingo Molnar
CommitDate: Thu, 28 May 2015 11:08:38 +0200
x86/mm: Mark arch_ioremap_p
... as their only caller is.
Signed-off-by: Jan Beulich
---
arch/x86/mm/ioremap.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc5/arch/x86/mm/ioremap.c
+++ 4.1-rc5-x86-ioremap-huge-supported/arch/x86/mm/ioremap.c
@@ -331,7 +331,7 @@ void iounmap(volatile void __iomem
Older compilers don't recognize that "v" can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich
---
drivers/tty/hvc/hvc_xen.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 4.1-r
Older compilers don't recognize that "v" can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_probe.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 4.1-r
... when the checked expression is compile time constant.
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int __init
AULT_FRAME capable of expressing both.
Signed-off-by: Jan Beulich
Cc: Denys Vlasenko
Cc: Andy Lutomirski
---
arch/x86/kernel/entry_64.S | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- 4.1-rc5/arch/x86/kernel/entry_64.S
+++ 4.1-rc5-x86_64-unwind-info/arch/x86/kerne
While commit efa7045103 ("x86/asm/entry: Make user_mode() work
correctly if regs came from VM86 mode") claims that "user_mode() is now
identical to user_mode_vm()", this wasn't actually the case - no prior
commit made it so.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
-
Older compilers don't recognize that v can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/tty/hvc/hvc_xen.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 4.1
... as their only caller is.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/mm/ioremap.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc5/arch/x86/mm/ioremap.c
+++ 4.1-rc5-x86-ioremap-huge-supported/arch/x86/mm/ioremap.c
@@ -331,7 +331,7 @@ void iounmap
While commit efa7045103 (x86/asm/entry: Make user_mode() work
correctly if regs came from VM86 mode) claims that user_mode() is now
identical to user_mode_vm(), this wasn't actually the case - no prior
commit made it so.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Andy Lutomirski l
Older compilers don't recognize that v can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/xenbus/xenbus_probe.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 4.1
capable of expressing both.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/entry_64.S | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- 4.1-rc5/arch/x86/kernel/entry_64.S
... when the checked expression is compile time constant.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int
On 28.05.15 at 11:01, mi...@kernel.org wrote:
* Jan Beulich jbeul...@suse.com wrote:
--- 4.1-rc5/arch/x86/kernel/entry_64.S
+++ 4.1-rc5-x86_64-unwind-info/arch/x86/kernel/entry_64.S
@@ -148,7 +148,7 @@ ENDPROC(native_usergs_sysret64)
/*
* frame that enables passing a complete pt_regs
On 28.05.15 at 12:36, david.vra...@citrix.com wrote:
On 28/05/15 09:23, Jan Beulich wrote:
... when the checked expression is compile time constant.
Commit messages should be complete sentences, please.
Do you mean I should repeat the start of the sentence from the
title in the body?
Jan
On 28.05.15 at 13:20, mi...@kernel.org wrote:
* Jan Beulich jbeul...@suse.com wrote:
Not sure why assembly code should look like C code. It's a matter of taste
perhaps, and I can see your point, but I'm also not really eager to do
changes
just to match other people's taste. And just like
Commit-ID: 1e6277de3a23373b89e0affc3d179f2173b857a4
Gitweb: http://git.kernel.org/tip/1e6277de3a23373b89e0affc3d179f2173b857a4
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Thu, 28 May 2015 09:29:27 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 28 May 2015 11:08:38
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
v2: Drop the description at David's request.
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int __init
>>> On 07.05.15 at 08:02, wrote:
> AFAICT gas will produce relocations for jumps to global labels in the
> same file. This doesn't seem directly harmful to me, except that, on
> x86, it forces five-byte jumps instead of two-byte jumps.
>
> This seems especially unfortunate, since even hidden
On 07.05.15 at 08:02, l...@amacapital.net wrote:
AFAICT gas will produce relocations for jumps to global labels in the
same file. This doesn't seem directly harmful to me, except that, on
x86, it forces five-byte jumps instead of two-byte jumps.
This seems especially unfortunate, since
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
On 23.04.15 at 17:33, torva...@linux-foundation.org wrote:
On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich jbeul...@suse.com wrote:
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
On 23.04.15 at 17:33, torva...@linux-foundation.org wrote:
On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich jbeul...@suse.com wrote:
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination
Linus,
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination address is expected to be in kernel space but accesses
may still fault. I.e. the use of plain memset() causes
__probe_kernel_write()
Linus,
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination address is expected to be in kernel space but accesses
may still fault. I.e. the use of plain memset() causes
__probe_kernel_write()
>>> On 20.04.15 at 19:09, wrote:
> A different approach, given the dual nature of the AC flag now is to gate
> setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a
> paravirtual situation where the kernel runs in cpl > 0.
"Can't" isn't true here - for 64-bit PV Xen guests,
On 20.04.15 at 19:09, andrew.coop...@citrix.com wrote:
A different approach, given the dual nature of the AC flag now is to gate
setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a
paravirtual situation where the kernel runs in cpl 0.
Can't isn't true here - for 64-bit PV
>>> On 10.04.15 at 16:37, wrote:
> On 03/04/15 15:28, Konrad Rzeszutek Wilk wrote:
>> Hey David and Boris,
>>
>> Please see the two patches - the first one fixes an situation that
>> the original XSA-120 patch hadn't considered.
>>
>> The second patch is more of just a cleanup. Can be 4.1
On 10.04.15 at 16:37, david.vra...@citrix.com wrote:
On 03/04/15 15:28, Konrad Rzeszutek Wilk wrote:
Hey David and Boris,
Please see the two patches - the first one fixes an situation that
the original XSA-120 patch hadn't considered.
The second patch is more of just a cleanup. Can be
>>> On 11.04.15 at 01:05, wrote:
>> One might argue that this code serves no purpose, but it's there, so
>> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still uses it.
I didn't have
On 11.04.15 at 01:05, a...@firstfloor.org wrote:
One might argue that this code serves no purpose, but it's there, so
we had better keep our per-invocation usage of DEBUG_STACK within 4k.
Only if you run NKLD. I doubt KDB or GDB support nesting.
We can ask Jan if he still uses it.
I
>>> On 23.03.15 at 23:58, wrote:
> On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
>> > A real world case is PCI_QUIRKS in the mainline kernel:
>> >
>> > init/Kconfig:1554: default y
>> > arch/s390/Kconfig:59: def_bool n
>> >
>> > When setting PCI!=n && EXPERT=n then on each
>>> On 23.03.15 at 22:08, wrote:
> On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
>> On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
>> > Default "no" is pretty pointless for options without (visible) prompts:
>>
>> Related:
On 23.03.15 at 22:08, walch.mar...@web.de wrote:
On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
Default no is pretty pointless for options without (visible) prompts:
Related: is there ever a situation where using default n
On 23.03.15 at 23:58, walch.mar...@web.de wrote:
On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
A real world case is PCI_QUIRKS in the mainline kernel:
init/Kconfig:1554: default y
arch/s390/Kconfig:59: def_bool n
When setting PCI!=n EXPERT=n then on each architecture
>>> On 12.03.15 at 13:11, wrote:
> On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
>> Default "no" is pretty pointless for options without (visible) prompts:
>
> Related: is there ever a situation where using "default n" or "def_bool
> n
>>> On 12.03.15 at 00:10, wrote:
> config X86_LOCAL_APIC
> def_bool y
> - depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC ||
> PCI_MSI
> + depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI
I.e. building a 32-bit kernel with APIC support but with !SMP,
On 12.03.15 at 00:10, mcg...@do-not-panic.com wrote:
config X86_LOCAL_APIC
def_bool y
- depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC ||
PCI_MSI
+ depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI
I.e. building a 32-bit kernel with APIC support but
On 12.03.15 at 13:11, pebo...@tiscali.nl wrote:
On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
Default no is pretty pointless for options without (visible) prompts:
Related: is there ever a situation where using default n or def_bool
n makes sense (whether or not the entry has
>>> On 11.03.15 at 15:44, wrote:
> On 11/03/15 14:42, Konrad Rzeszutek Wilk wrote:
>> On Wed, Mar 11, 2015 at 01:52:00PM +, Jan Beulich wrote:
>>> It's not clear to me why only the enabling operation got handled so
>>> far.
>>
>> Reviewed
Default "no" is pretty pointless for options without (visible) prompts:
They only clutter .config-s with "# CONFIG_... is not set" and thus
prevent users of "make oldconfig", when the option obtains a prompt or
its prompt becomes visible, noticing that these may now b
It's not clear to me why only the enabling operation got handled so
far.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- 4.0-rc3-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.
This is CVE-2015-2150 / XSA-120.
Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/xen/xen-pciback/conf_space.c|2
On 11.03.15 at 15:44, david.vra...@citrix.com wrote:
On 11/03/15 14:42, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 11, 2015 at 01:52:00PM +, Jan Beulich wrote:
It's not clear to me why only the enabling operation got handled so
far.
Reviewed-by: Konrad Rzeszutek Wilk konrad.w
Default no is pretty pointless for options without (visible) prompts:
They only clutter .config-s with # CONFIG_... is not set and thus
prevent users of make oldconfig, when the option obtains a prompt or
its prompt becomes visible, noticing that these may now be enabled.
Signed-off-by: Jan
that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.
This is CVE-2015-2150 / XSA-120.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/xen/xen
It's not clear to me why only the enabling operation got handled so
far.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/xen-pciback/conf_space_header.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- 4.0-rc3-xen-pciback.orig/drivers/xen/xen-pciback
>>> On 05.03.15 at 09:52, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, March 5, 2015 4:40 PM
>> >>> On 05.03.15 at 04:53, wrote:
>> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> >>
>>> On 05.03.15 at 04:53, wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: Thursday, March 5, 2015 3:43 AM
>> On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
>> > @@ -101,13 +119,32 @@ setup_io_tlb_npages(char *str) {
>> >if (isdigit(*str)) {
>> >
Cc: Greg Kroah-Hartman
> Cc: H. Peter Anvin
> Cc: jbeul...@suse.com
> Cc: Jan Beulich
> Cc: Joonsoo Kim
> Cc: Juergen Gross
> Cc: Linus Torvalds
> Cc: Pavel Machek
> Cc: Thomas Gleixner
> Cc: Tony Lindgren
> Cc: Toshi Kani
> Cc: Vlastimil Babka
> Cc: X
On 05.03.15 at 09:52, xiaoming.w...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, March 5, 2015 4:40 PM
On 05.03.15 at 04:53, xiaoming.w...@intel.com wrote:
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Thursday, March 5, 2015 3:43 AM
On 05.03.15 at 04:53, xiaoming.w...@intel.com wrote:
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Thursday, March 5, 2015 3:43 AM
On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
@@ -101,13 +119,32 @@ setup_io_tlb_npages(char *str) {
if
...@linux.intel.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Dexuan Cui de...@microsoft.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: jbeul...@suse.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Juergen Gross jgr
>>> On 04.03.15 at 05:53, wrote:
> On 03/03/2015 08:20 PM, Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel wrote:
>>> On 03/03/15 09:40, Luis R. Rodriguez wrote:
if X86_64 && SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to
On 04.03.15 at 05:53, jgr...@suse.com wrote:
On 03/03/2015 08:20 PM, Luis R. Rodriguez wrote:
On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel david.vra...@citrix.com wrote:
On 03/03/15 09:40, Luis R. Rodriguez wrote:
if X86_64 SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but
>>> On 03.03.15 at 10:40, wrote:
> Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
> selected on x86 when:
>
> if X86_64 && SPARSEMEM_VMEMMAP
>
> Now Xen should not have SPARSEMEM_VMEMMAP
Why would that be?
Jan
--
To unsubscribe from this list: send the line "unsubscribe
On 03.03.15 at 10:40, mcg...@suse.com wrote:
Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
selected on x86 when:
if X86_64 SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP
Why would that be?
Jan
--
To unsubscribe from this list: send the line unsubscribe
Commit-ID: 0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Gitweb: http://git.kernel.org/tip/0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 02:18:26 +0100
x86-64: Also clear
Commit-ID: db2dcb4f91d5fec5c346a82c309187ee821e2495
Gitweb: http://git.kernel.org/tip/db2dcb4f91d5fec5c346a82c309187ee821e2495
Author: Jan Beulich
AuthorDate: Tue, 20 Jan 2015 13:00:46 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 01:08:42 +0100
irqflags: Fix (at least
Commit-ID: 3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Gitweb: http://git.kernel.org/tip/3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 00:44:46 +0100
x86-64: Also clear
Commit-ID: 50849eefea3ba8aa6e540e0cbdc9533098f25656
Gitweb: http://git.kernel.org/tip/50849eefea3ba8aa6e540e0cbdc9533098f25656
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:31:56 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:10:54 +0100
x86/Kconfig: Simplify
Commit-ID: e0fd24a3b4ad7b4084b41944835952eedec53f98
Gitweb: http://git.kernel.org/tip/e0fd24a3b4ad7b4084b41944835952eedec53f98
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:39:34 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:08:46 +0100
x86/Kconfig: Avoid issuing
Commit-ID: b1da1e715d4faf01468b7f45f7098922bc85ea8e
Gitweb: http://git.kernel.org/tip/b1da1e715d4faf01468b7f45f7098922bc85ea8e
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:35:21 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:09:33 +0100
x86/Kconfig: Simplify
Commit-ID: 890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Gitweb: http://git.kernel.org/tip/890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Author: Jan Beulich
AuthorDate: Mon, 9 Feb 2015 12:30:00 +0100
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 16:18:02 +0100
sched/numa: Avoid some
>>> On 18.02.15 at 10:37, wrote:
> On 02/18/2015 10:21 AM, Paul Bolle wrote:
>> On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -23,14 +23,29 @@ config XEN_PVHVM
>>> def_bool y
>>> depends on XEN && PCI &&
>>> On 18.02.15 at 10:09, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, February 17, 2015 6:09 PM
>> >>> On 17.02.15 at 07:51, wrote:
>> > --- a/Documentation/kernel-parameters.txt
>> > +++ b/Documentation/ke
On 18.02.15 at 10:37, jgr...@suse.com wrote:
On 02/18/2015 10:21 AM, Paul Bolle wrote:
On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -23,14 +23,29 @@ config XEN_PVHVM
def_bool y
depends on XEN PCI X86_LOCAL_APIC
On 18.02.15 at 10:09, xiaoming.w...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, February 17, 2015 6:09 PM
On 17.02.15 at 07:51, xiaoming.w...@intel.com wrote:
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10
Commit-ID: 890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Gitweb: http://git.kernel.org/tip/890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 9 Feb 2015 12:30:00 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 18 Feb 2015 16:18:02
Commit-ID: db2dcb4f91d5fec5c346a82c309187ee821e2495
Gitweb: http://git.kernel.org/tip/db2dcb4f91d5fec5c346a82c309187ee821e2495
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 20 Jan 2015 13:00:46 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 19 Feb 2015 01:08:42
Commit-ID: 3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Gitweb: http://git.kernel.org/tip/3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 19 Feb 2015 00:44:46
Commit-ID: b1da1e715d4faf01468b7f45f7098922bc85ea8e
Gitweb: http://git.kernel.org/tip/b1da1e715d4faf01468b7f45f7098922bc85ea8e
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Thu, 5 Feb 2015 15:35:21 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 18 Feb 2015 22:09:33
Commit-ID: 0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Gitweb: http://git.kernel.org/tip/0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 19 Feb 2015 02:18:26
701 - 800 of 2685 matches
Mail list logo
