RE: [PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread Jan Beulich
>>> On 21.11.18 at 14:49, wrote: > From: Jan Beulich >> Sent: 21 November 2018 13:03 >> >> >>> On 21.11.18 at 12:55, wrote: >> > From: Jan Beulich >> >> Sent: 21 November 2018 10:11 >> >> >> >> Add mi

RE: [PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread Jan Beulich
>>> On 21.11.18 at 12:55, wrote: > From: Jan Beulich >> Sent: 21 November 2018 10:11 >> >> Add missing insn suffixes and use rmwcc.h just like was (more or less) >> recently done for bitops.h as well. > > Why? bts (etc) on memory don't really

[PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread Jan Beulich
Add missing insn suffixes and use rmwcc.h just like was (more or less) recently done for bitops.h as well. Signed-off-by: Jan Beulich --- v2: Re-base over rmwcc.h changes. --- arch/x86/include/asm/sync_bitops.h | 31 +-- 1 file changed, 9 insertions(+), 22

Re: [PATCH v2] x86-64: use 32-bit XOR to zero registers

2018-07-09 Thread Jan Beulich
>>> On 09.07.18 at 10:33, wrote: > Anyway, normally assembler is the one who chooses instruction > encoding. There are different possible views here, and I personally think that while it is a compiler's job to chose optimal encodings, assemblers shouldn't by default alter what the programmer (or

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

2018-07-03 Thread Jan Beulich
>>> On 03.07.18 at 10:46, wrote: > From: Jan Beulich >> Sent: 03 July 2018 09:36 > ... >> As said there, omitting suffixes from instructions in AT mode is bad >> practice when operand size cannot be determined by the assembler from >> register operands,

[tip:x86/asm] x86/asm/64: Use 32-bit XOR to zero registers

2018-07-03 Thread tip-bot for Jan Beulich
Commit-ID: a7bea8308933aaeea76dad7d42a6e51000417626 Gitweb: https://git.kernel.org/tip/a7bea8308933aaeea76dad7d42a6e51000417626 Author: Jan Beulich AuthorDate: Mon, 2 Jul 2018 04:31:54 -0600 Committer: Ingo Molnar CommitDate: Tue, 3 Jul 2018 09:59:29 +0200 x86/asm/64: Use 32-bit XOR

[tip:x86/asm] x86/entry/64: Add two more instruction suffixes

2018-07-03 Thread tip-bot for Jan Beulich
Commit-ID: 6709812f094d96543b443645c68daaa32d3d3e77 Gitweb: https://git.kernel.org/tip/6709812f094d96543b443645c68daaa32d3d3e77 Author: Jan Beulich AuthorDate: Mon, 2 Jul 2018 04:47:57 -0600 Committer: Ingo Molnar CommitDate: Tue, 3 Jul 2018 09:59:29 +0200 x86/entry/64: Add two more

[PATCH] x86/entry/64: add two more instruction suffixes

2018-07-02 Thread Jan Beulich
r operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the other missing suffixes here as well. Signed-off-by: Jan Beulich --- arch/x86/entry/entry_64.S |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 4.18-rc3/arch/x86/entry/

[PATCH v2] x86-64: use 32-bit XOR to zero registers

2018-07-02 Thread Jan Beulich
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms. Zeroing idioms don't require execution bandwidth, as they're being taken care of in the frontend (through register renaming). Use 32-bit XORs instead. Signed-off-by: Jan Beulich --- v2: Explain what zeroing idioms are/do

[tip:x86/urgent] x86/entry/32: Add explicit 'l' instruction suffix

2018-06-26 Thread tip-bot for Jan Beulich
Commit-ID: 236f0cd286b67291796362feeac4f342900cfa82 Gitweb: https://git.kernel.org/tip/236f0cd286b67291796362feeac4f342900cfa82 Author: Jan Beulich AuthorDate: Mon, 25 Jun 2018 04:21:59 -0600 Committer: Ingo Molnar CommitDate: Tue, 26 Jun 2018 09:20:31 +0200 x86/entry/32: Add explicit

Re: [PATCH] x86: modernize sync_bitops.h

2018-06-26 Thread Jan Beulich
>>> On 26.06.18 at 09:18, wrote: > * Jan Beulich wrote: > >> Add missing insn suffixes and use rmwcc.h just like was (more or less) >> recently done for bitops.h as well. >> >> Signed-off-by: Jan Beulich >> ---

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

2018-06-26 Thread Jan Beulich
>>> On 25.06.18 at 18:33, wrote: > On 06/25/2018 03:25 AM, Jan Beulich wrote: >> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use >> 32-bit ones instead. > > Hmph. Is that considered a bug (errata)? No. > URL/references? Intel's Opti

[PATCH] x86-64: use 32-bit XOR to zero registers

2018-06-25 Thread Jan Beulich
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use 32-bit ones instead. Signed-off-by: Jan Beulich --- arch/x86/crypto/aegis128-aesni-asm.S |2 +- arch/x86/crypto/aegis128l-aesni-asm.S|2 +- arch/x86/crypto/aegis256-aesni-asm.S |2 +- arch/x86/crypto

[PATCH] x86: modernize sync_bitops.h

2018-06-25 Thread Jan Beulich
Add missing insn suffixes and use rmwcc.h just like was (more or less) recently done for bitops.h as well. Signed-off-by: Jan Beulich --- arch/x86/include/asm/sync_bitops.h | 34 -- 1 file changed, 12 insertions(+), 22 deletions(-) --- 4.18-rc2/arch/x86

[PATCH] ix86/entry: add instruction suffix

2018-06-25 Thread Jan Beulich
Omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the single missing suffix here. Signed-off-by: Jan Beulich

Re: [PATCH v5 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-23 Thread Jan Beulich
>>> On 23.05.18 at 16:30, wrote: > @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen) > /* 64-bit entry point. */ > .code64 > 1: > + /* Set base address in stack canary descriptor. */ > + mov $MSR_GS_BASE,%ecx > + mov $_pa(canary), %rax > + xor %rdx,

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-23 Thread Jan Beulich
>>> On 22.05.18 at 19:10, <boris.ostrov...@oracle.com> wrote: > On 05/22/2018 12:32 PM, Jan Beulich wrote: >>>>> On 22.05.18 at 18:20, <boris.ostrov...@oracle.com> wrote: >>> We are loading virtual address for $canary so we will always have EDX >&

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-22 Thread Jan Beulich
>>> On 22.05.18 at 18:20, <boris.ostrov...@oracle.com> wrote: > On 05/22/2018 12:10 PM, Jan Beulich wrote: >>>>> On 22.05.18 at 17:15, <brge...@gmail.com> wrote: >>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: &

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-22 Thread Jan Beulich
>>> On 22.05.18 at 17:15, <brge...@gmail.com> wrote: > On Tue, May 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 22.05.18 at 15:45, <brge...@gmail.com> wrote: >>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky >>

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-22 Thread Jan Beulich
>>> On 22.05.18 at 15:45, wrote: > On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky > wrote: >> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen) >> /* 64-bit entry point. */ >> .code64 >> 1: >> + /* Set base address in stack canary

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-22 Thread Jan Beulich
>>> On 22.05.18 at 05:54, <boris.ostrov...@oracle.com> wrote: > We are making calls to C code (e.g. xen_prepare_pvh()) which may use > stack canary (stored in GS segment). > > Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Reviewed-by: Jan Beulich <jbeul...@suse.com>

Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-18 Thread Jan Beulich
>>> On 17.05.18 at 19:47, <boris.ostrov...@oracle.com> wrote: > On 05/17/2018 11:02 AM, Jan Beulich wrote: >>>>> On 17.05.18 at 16:47, <boris.ostrov...@oracle.com> wrote: >>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) >>> mov %eax,%es &g

Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-17 Thread Jan Beulich
>>> On 17.05.18 at 16:47, wrote: > @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + mov $PVH_CANARY_SEL,%eax > + mov %eax,%gs I doubt this is needed for 64-bit (you could equally well load zero or leave in place what's

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

2018-05-17 Thread Jan Beulich
>>> On 16.05.18 at 18:44, <na...@vmware.com> wrote: > Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 15.05.18 at 16:11, <na...@vmware.com> wrote: >>> --- a/arch/x86/include/asm/refcount.h >>> +++ b/arch/x86/include/asm/refco

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

2018-05-16 Thread Jan Beulich
>>> On 15.05.18 at 16:11, wrote: > --- a/arch/x86/include/asm/refcount.h > +++ b/arch/x86/include/asm/refcount.h > @@ -14,34 +14,43 @@ > * central refcount exception. The fixup address for the exception points > * back to the regular execution flow in .text. > */ >

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

2018-05-14 Thread Jan Beulich
>>> On 09.05.18 at 22:33, wrote: > @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + /* Set base address in stack canary descriptor. */ > + movl _pa(gdt_start),%eax > + movl $_pa(canary),%ecx > + movw %cx,

Re: [PATCH] x86-64/Xen: fix stack switching

2018-05-14 Thread Jan Beulich
>>> On 08.05.18 at 04:38, <l...@kernel.org> wrote: > On Mon, May 7, 2018 at 5:16 AM Jan Beulich <jbeul...@suse.com> wrote: > >> While on native entry into the kernel happens on the trampoline stack, >> PV Xen kernels are being entered with the current t

[PATCH] x86-64/Xen: fix stack switching

2018-05-07 Thread Jan Beulich
path is unreachable when running an PV Xen guest afaict. Signed-off-by: Jan Beulich <jbeul...@suse.com> Cc: sta...@kernel.org --- There would certainly have been the option of using alternatives patching, but afaict the patching code isn't NMI / #MC safe, so I'd rather stay away from pa

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

2018-05-03 Thread Jan Beulich
>>> On 02.05.18 at 19:29, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:41 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:22, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>>>> On

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 17:22, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:00, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 17:08, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:00 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 16:57, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>>>> O

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 17:06, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:26 AM, Jan Beulich wrote: >>>>> On 01.05.18 at 14:34, <boris.ostrov...@oracle.com> wrote: >>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >>>> On

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 17:00, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >>> --- a/arch/x86/xen/xen-pvh.S >>> +++ b/arch/x86/xen/xen-pvh.S &g

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 16:57, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >>> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

2018-05-02 Thread Jan Beulich
>>> On 01.05.18 at 14:34, wrote: > On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: >>> And without it we can't use _BOOT_XX macros any longer so define new ones. >> >> Not being that familiar with

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

2018-05-02 Thread Jan Beulich
>>> On 30.04.18 at 18:23, wrote: > And without it we can't use _BOOT_XX macros any longer so define new ones. Ah, here we go. Perhaps this should be moved earlier in the series? Assuming you really want to go this route in the first place, taking Roger's comment into

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

2018-05-02 Thread Jan Beulich
>>> On 30.04.18 at 18:23, wrote: > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -54,6 +54,9 @@ > * charge of setting up it's own stack, GDT and IDT. > */ > > +#define PVH_GDT_ENTRY_CANARY4 > +#define PVH_CANARY_SEL

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

2018-05-02 Thread Jan Beulich
>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: > Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Reviewed-by: Jan Beulich <jbeul...@suse.com> But to understand why things have been working nevertheless it would have been nice if t

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

2018-05-02 Thread Jan Beulich
>>> On 30.04.18 at 18:23, wrote: > Latest binutils release (2.29.1) will no longer allow proper computation > of GDT entries on 32-bits, with warning: > > arch/x86/xen/xen-pvh.S: Assembler messages: > arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

2018-05-02 Thread Jan Beulich
>>> On 02.05.18 at 03:56, <douly.f...@cn.fujitsu.com> wrote: > At 04/27/2018 08:09 PM, Jan Beulich wrote: >> I'm afraid I don't understand: Limiting the number of disabled CPUs is >> certainly desirable when those can never be used, but why would you >> want

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

2018-04-27 Thread Jan Beulich
>>> On 27.04.18 at 10:32, <douly.f...@cn.fujitsu.com> wrote: > At 04/27/2018 03:21 PM, Jan Beulich wrote: >> I've just stumbled across this commit, and I'm wondering if that's actually >> correct (I too have at least one system where such IDs are reported in >

recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

2018-04-27 Thread Jan Beulich
Hello, I've just stumbled across this commit, and I'm wondering if that's actually correct (I too have at least one system where such IDs are reported in MADT): For offline/absent CPUs, the firmware may not know the APIC IDs at the point MADT is built, so I think it is quite reasonable to put ~0

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

2018-04-12 Thread Jan Beulich
>>> On 12.04.18 at 09:32, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 11.04.18 at 13:53, <mi...@kernel.org> wrote: >> > * Jan Beulich <jbeul...@suse.com> wrote: >> > >> >

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

2018-04-11 Thread Jan Beulich
>>> On 11.04.18 at 13:53, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> Additionally, x86 maintainers: is there a particular reason this (or >> any functionally equivalent patch) isn't upstream yet? As indicated >> befor

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

2018-04-11 Thread Jan Beulich
>>> On 11.04.18 at 09:08, <jgr...@suse.com> wrote: > On 14/03/18 09:48, Jan Beulich wrote: >>>>> On 26.02.18 at 15:08, <jgr...@suse.com> wrote: >>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) >>&

Re: [PATCH] [v3] xen: remove pre-xen3 fallback handlers

2018-03-15 Thread Jan Beulich
>>> On 14.03.18 at 23:47, wrote: > On 03/13/2018 05:06 PM, Arnd Bergmann wrote: >> The legacy hypercall handlers were originally added with >> a comment explaining that "copying the argument structures in >> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op()

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

2018-03-14 Thread Jan Beulich
>>> On 26.02.18 at 15:08, wrote: > @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) > > static void xen_vcpu_notify_restore(void *data) > { > + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) > + wrmsrl(MSR_IA32_SPEC_CTRL,

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

2018-02-28 Thread Jan Beulich
Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information

[tip:x86/urgent] x86/asm: Add instruction suffixes to bitops

2018-02-28 Thread tip-bot for Jan Beulich
Commit-ID: 22636f8c9511245cb3c8412039f1dd95afb3aa59 Gitweb: https://git.kernel.org/tip/22636f8c9511245cb3c8412039f1dd95afb3aa59 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 26 Feb 2018 04:11:51 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Wed,

[tip:x86/urgent] x86/entry/64: Add instruction suffix

2018-02-28 Thread tip-bot for Jan Beulich
Commit-ID: a368d7fd2a3c6babb852fe974018dd97916bcd3b Gitweb: https://git.kernel.org/tip/a368d7fd2a3c6babb852fe974018dd97916bcd3b Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 26 Feb 2018 04:11:21 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Wed,

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

2018-02-26 Thread Jan Beulich
@vger.kernel.org > Signed-off-by: Juergen Gross <jgr...@suse.com> Reviewed-by: Jan Beulich <jbeul...@suse.com>

[PATCH] x86/include: add instruction suffixes

2018-02-26 Thread Jan Beulich
some operations change from being 32-bit to 64-bit. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- If the operand size change for 64-bit is undesirable, further transformations would be necessary. Likely the best route would be to fully separate the constant and variable bit position case

[PATCH] x86-64/entry: add instruction suffix

2018-02-26 Thread Jan Beulich
Omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the single missing suffix here. Signed-off-by: Jan Beulich

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

2018-02-26 Thread Jan Beulich
>>> On 26.02.18 at 11:47, <aryabi...@virtuozzo.com> wrote: > > On 02/26/2018 01:08 PM, Jan Beulich wrote: >>>>> On 26.02.18 at 11:00, <aryabi...@virtuozzo.com> wrote: >>> On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >>>>

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

2018-02-26 Thread Jan Beulich
>>> On 26.02.18 at 11:00, <aryabi...@virtuozzo.com> wrote: > On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >> @@ -351,7 +362,7 @@ static inline bool kasan_page_table(struct seq_file *m, >> struct pg_state *st, >> (pgtable_l5_enable

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

2018-02-26 Thread tip-bot for Jan Beulich
Commit-ID: 672c0ae09b33a11d8f31fc61526632e96301164c Gitweb: https://git.kernel.org/tip/672c0ae09b33a11d8f31fc61526632e96301164c Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 26 Fe

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

2018-02-23 Thread tip-bot for Jan Beulich
Commit-ID: 6e558c9d10146ebe7f04917af2f8533b811f9c25 Gitweb: https://git.kernel.org/tip/6e558c9d10146ebe7f04917af2f8533b811f9c25 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 23 Fe

[PATCH v3] x86: consider effective protection attributes in W+X check

2018-02-23 Thread Jan Beulich
_NX is set in L2. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v3: Fix build issue with CONFIG_KASAN. v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 94 +++

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

2018-02-22 Thread Jan Beulich
>>> On 23.02.18 at 08:49, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 21.02.18 at 17:53, <mi...@kernel.org> wrote: >> >> > * Jan Beulich <jbeul...@suse.com> wrote: >> >

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

2018-02-22 Thread Jan Beulich
>>> On 21.02.18 at 17:53, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. >>

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

2018-02-22 Thread Jan Beulich
>>> On 21.02.18 at 22:39, <keesc...@chromium.org> wrote: > On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich <jbeul...@suse.com> wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operati

[PATCH v2] x86: consider effective protection attributes in W+X check

2018-02-21 Thread Jan Beulich
_NX is set in L2. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

2018-02-20 Thread Jan Beulich
>>> On 20.02.18 at 11:17, wrote: > I assume the Xen fix got merged meanwhile? Yes (that's the commit I've referred to in an earlier reply). Jan

[tip:x86/pti] x86/LDT: Avoid warning in 32-bit builds with older gcc

2018-02-20 Thread tip-bot for Jan Beulich
Commit-ID: f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Gitweb: https://git.kernel.org/tip/f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:52:10 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86-64/realmode: Add instruction suffix

2018-02-20 Thread tip-bot for Jan Beulich
Commit-ID: 8554004a0231dedf44d4d62147fb3d6a6db489aa Gitweb: https://git.kernel.org/tip/8554004a0231dedf44d4d62147fb3d6a6db489aa Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 08:06:14 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/IO-APIC: Avoid warning in 32-bit builds

2018-02-20 Thread tip-bot for Jan Beulich
Commit-ID: 6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Gitweb: https://git.kernel.org/tip/6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:50:23 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/asm: Improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

2018-02-20 Thread tip-bot for Jan Beulich
Commit-ID: 700b7c5409c3e9da279fbea78cf28a78fbc176cd Gitweb: https://git.kernel.org/tip/700b7c5409c3e9da279fbea78cf28a78fbc176cd Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:49:12 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/mm: Fix {pmd,pud}_{set,clear}_flags()

2018-02-20 Thread tip-bot for Jan Beulich
Commit-ID: 842cef9113c2120f74f645111ded1e020193d84c Gitweb: https://git.kernel.org/tip/842cef9113c2120f74f645111ded1e020193d84c Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:48:11 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

2018-02-20 Thread Jan Beulich
>>> On 20.02.18 at 09:37, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> I'll see what I can do; it's a pity that the change here, which had >> been sent weeks ago and is a bug fix, hadn't gone in before that >> other cha

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

2018-02-20 Thread Jan Beulich
>>> On 20.02.18 at 09:10, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. > > Under wha

[PATCH RESEND] x86: consider effective protection attributes in W+X check

2018-02-19 Thread Jan Beulich
entry's value). Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed, 57 insertions(+), 35 deletions(-) --- 4.16-rc2/arch/x86/mm/dump_pagetable

Re: [PATCH] x86: fix {pmd,pud}_{set,clear}_flags()

2018-02-19 Thread Jan Beulich
>>> On 19.02.18 at 17:23, <jgr...@suse.com> wrote: > On 19/02/18 15:48, Jan Beulich wrote: >> Just like pte_{set,clear}_flags() their PMD and PUD counterparts should >> not do any address translation. This was outright wrong under Xen >> (causing a dead boo

[PATCH] x86-64/realmode: add instruction suffix

2018-02-19 Thread Jan Beulich
Omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the single missing suffix here. Signed-off-by: Jan Beulich

[PATCH] x86/LDT: avoid warning in 32-bit builds with older gcc

2018-02-19 Thread Jan Beulich
BUG() doesn't always imply "no return", and hence should be followed by a return statement even if that's obviously (to a human) unreachable. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/include/asm/mmu_context.h |1 + 1 file changed, 1 insertion(+) --- 4

[PATCH] x86/IO-APIC: avoid warning in 32-bit builds

2018-02-19 Thread Jan Beulich
Constants wider than 32 bits should be tagged with ULL. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/kernel/apic/io_apic.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 4.16-rc2/arch/x86/kernel/apic/io_apic.c +++ 4.16-rc2-ix86-IO-APIC-constant/arch/x86/kerne

[PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

2018-02-19 Thread Jan Beulich
ich this particular invocation needs. Drop the "cc" clobber altogether and move the "cx" one to refcount.h. Signed-off-by: Jan Beulich <jbeul...@suse.com> Cc: Kees Cook <keesc...@chromium.org> --- arch/x86/include/asm/refcount.h |4 ++-- arch/x86/inclu

[PATCH] x86: fix {pmd,pud}_{set,clear}_flags()

2018-02-19 Thread Jan Beulich
n paravirt was enabled. Signed-off-by: Jan Beulich <jbeul...@suse.com> Cc: sta...@vger.kernel.org --- arch/x86/include/asm/pgtable.h |8 arch/x86/include/asm/pgtable_types.h | 10 ++ 2 files changed, 14 insertions(+), 4 deletions(-) --- 4.16-rc2/arch/x86/include/asm/pg

Re: [Xen-devel] [PATCH] [v2] xen: hypercall: fix out-of-bounds memcpy

2018-02-05 Thread Jan Beulich
>>> On 05.02.18 at 16:03, wrote: > int xen_event_channel_op_compat(int cmd, void *arg) > { > - struct evtchn_op op; > + struct evtchn_op op = { .cmd = cmd, }; > + size_t len; > int rc; > > - op.cmd = cmd; > - memcpy(, arg, sizeof(op.u)); > - rc =

Re: [Xen-devel] [PATCH v2] xen/balloon: Mark unallocated host memory as UNUSABLE

2017-12-19 Thread Jan Beulich
>>> On 19.12.17 at 16:03, <boris.ostrov...@oracle.com> wrote: > On 12/19/2017 09:40 AM, Jan Beulich wrote: >>>>> On 19.12.17 at 15:25, <boris.ostrov...@oracle.com> wrote: >>> On 12/19/2017 03:23 AM, Jan Beulich wrote: >>>&g

Re: [Xen-devel] [PATCH v2] xen/balloon: Mark unallocated host memory as UNUSABLE

2017-12-19 Thread Jan Beulich
>>> On 19.12.17 at 15:25, <boris.ostrov...@oracle.com> wrote: > On 12/19/2017 03:23 AM, Jan Beulich wrote: >>>>> On 18.12.17 at 23:22, <boris.ostrov...@oracle.com> wrote: >>> + if (!xen_e820_table) >>> + return; >> N

Re: [Xen-devel] [PATCH v2] xen/balloon: Mark unallocated host memory as UNUSABLE

2017-12-19 Thread Jan Beulich
>>> On 19.12.17 at 10:21, <jgr...@suse.com> wrote: > On 19/12/17 09:23, Jan Beulich wrote: >>>>> On 18.12.17 at 23:22, <boris.ostrov...@oracle.com> wrote: >>> +void __init arch_xen_balloon_init(struct resource *hostmem_resource) >>>

Re: [Xen-devel] [PATCH v2] xen/balloon: Mark unallocated host memory as UNUSABLE

2017-12-19 Thread Jan Beulich
>>> On 18.12.17 at 23:22, wrote: > +void __init arch_xen_balloon_init(struct resource *hostmem_resource) > +{ > + struct xen_memory_map memmap; > + int rc; > + unsigned int i, last_guest_ram; > + phys_addr_t max_addr = max_pfn << PAGE_SHIFT; PFN_PHYS()

[PATCH v3] x86-64/Xen: eliminate W+X mappings

2017-12-18 Thread Jan Beulich
it is supposed to do, call get_cpu_cap() first. This was broken by commit 4763ed4d45 ("x86, mm: Clean up and simplify NX enablement") when switching away from the direct EFER read. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com&

[PATCH v2] x86-64/Xen: eliminate W+X mappings

2017-12-18 Thread Jan Beulich
it is supposed to do, call get_cpu_cap() first. This was broken by commit 4763ed4d45 ("x86, mm: Clean up and simplify NX enablement") when switching away from the direct EFER read. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- v2: Adjust comment style and indentation. --- W

Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

2017-12-17 Thread Jan Beulich
>>> On 15.12.17 at 20:52, wrote: +static int pcistub_device_reset(struct pci_dev *dev) +{ + struct xen_pcibk_dev_data *dev_data; + bool slot = false, bus = false; + struct pcistub_args arg = {}; + + if (!dev) + return

Re: [PATCH 1/2] x86: consider effective protection attributes in W+X check

2017-12-14 Thread Jan Beulich
>>> On 14.12.17 at 15:04, <jgr...@suse.com> wrote: > On 12/12/17 11:31, Jan Beulich wrote: >> @@ -335,42 +346,45 @@ static inline bool kasan_page_table(stru >> >> #if PTRS_PER_PMD > 1 >> >> -static void walk_pmd_level(struct seq_file *m, s

Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

2017-12-12 Thread Jan Beulich
>>> On 12.12.17 at 15:48, wrote: > Thanks Jan for your review comments. Please see below for my comments. First of all - can you please do something about your reply style? HTML mail should be avoided. You'll see that the (plain text) reply as a result is rather hard to

Re: [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

2017-12-12 Thread Jan Beulich
>>> On 12.12.17 at 11:38, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: >> --- 4.15-rc3/arch/x86/xen/mmu_pv.c >> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c >> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pageta

Re: [PATCH 1/2] x86: consider effective protection attributes in W+X check

2017-12-12 Thread Jan Beulich
>>> On 12.12.17 at 11:36, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. > >

[PATCH 2/2] x86-64/Xen: eliminate W+X mappings

2017-12-12 Thread Jan Beulich
it is supposed to do, call get_cpu_cap() first. This was broken by commit 4763ed4d45 ("x86, mm: Clean up and simplify NX enablement") when switching away from the direct EFER read. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- While I certainly dislike the added header inc

[PATCH 1/2] x86: consider effective protection attributes in W+X check

2017-12-12 Thread Jan Beulich
entry's value). Signed-off-by: Jan Beulich <jbeul...@suse.com> --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed, 57 insertions(+), 35 deletions(-) --- 4.15-rc3/arch/x86/mm/dump_pagetables.c +++ 4.15-rc3-x86-dumppgt-effective-prot/arch/

[PATCH 0/2] x86: deal with remaining W+X pages on Xen

2017-12-12 Thread Jan Beulich
The two patches here are entirely independent (i.e. they could by applied in any order and/or go through separate trees), but for the warning to go away both are necessary. 1: x86: consider effective protection attributes in W+X check 2: x86-64/Xen: eliminate W+X pages Signed-off-by: Jan Beulich

Re: [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

2017-12-12 Thread Jan Beulich
>>> On 11.12.17 at 22:59, <pbonz...@redhat.com> wrote: > On 08/12/2017 09:49, Jan Beulich wrote: >>> + * The layout of each entry in the memory map table is as follows and no >>> + * padding is used between entries in the array: >>> + * &g

Re: [Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests

2017-12-11 Thread Jan Beulich
>>> On 08.12.17 at 16:11, wrote: > Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212 > which should have been 0x020c. This part of the description has become partly stale now with the new patch 3. Jan

Re: [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

2017-12-11 Thread Jan Beulich
>>> On 08.12.17 at 20:05, <maran.wil...@oracle.com> wrote: > On 12/8/2017 12:49 AM, Jan Beulich wrote: >> I'm not convinced of re-using E820 types here. I can see that this >> might ease the consumption in Linux, but I don't think there should >> be any conne

Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

2017-12-08 Thread Jan Beulich
>>> On 07.12.17 at 23:21, wrote: > Due to the complexity with the PCI lock we cannot do the reset when a > device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind') > as the pci_[slot|bus]_reset also takes the same lock resulting in a > dead-lock. It

Re: [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

2017-12-08 Thread Jan Beulich
>>> On 07.12.17 at 23:45, wrote: > The start info structure that is defined as part of the x86/HVM direct > boot ABI and used for starting Xen PVH guests would be more versatile if > it also included a way to efficiently pass information about the memory > map to the

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

2017-12-08 Thread Jan Beulich
>>> On 08.12.17 at 08:16, wrote: > Also, a more fundamental question: why doesn't Xen use EFI to hand over > hardware configuration details? Iirc the main purpose of the change here is to allow booting PVH (guest or Dom0) with Grub2 in the middle. PVH, at least for the time

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

2017-12-04 Thread Jan Beulich
>>> On 04.12.17 at 17:16, wrote: > Do you have any further comments on the current version of this patch?. No. I'm not fully understanding your most recent slot related comments, but I'll trust you and Konrad to get this into suitable shape. Jan

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

2017-11-30 Thread Jan Beulich
>>> On 30.11.17 at 15:15, <govinda.ta...@oracle.com> wrote: > On 11/30/2017 2:27 AM, Jan Beulich wrote: >>>>> On 29.11.17 at 18:38, <govinda.ta...@oracle.com> wrote: >>>>> In the case of bus or slot reset, our goal is to reset connected PCI

  1   2   3   4   5   6   7   8   9   10   >