Re: [PATCH] x86_32: add support for 64 bit __get_user()

On 03/09/2016 09:50 AM, Benjamin LaHaise wrote: > On Wed, Mar 09, 2016 at 09:36:30AM -0800, H. Peter Anvin wrote: >> On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise wrote: >>> The existing __get_user() implementation does not support fetching >>> 64 bit values on 32

Re: [PATCH] x86_32: add support for 64 bit __get_user()

On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise wrote: >The existing __get_user() implementation does not support fetching >64 bit values on 32 bit x86. Implement this in a way that does not >generate any incorrect warnings as cautioned by Russell King. Test >code available at http://www.kva

Re: [PATCH] x86/entry: Improve system call entry comments

On 03/08/16 10:50, Andy Lutomirski wrote: > On Tue, Mar 8, 2016 at 10:47 AM, H. Peter Anvin wrote: >> On 03/08/16 10:45, Andy Lutomirski wrote: >>> >>> s/modern/most, perhaps? >>> >>> I'm hoping that some day Bionic goes away and gets replaced b

Re: [PATCH] x86/entry: Improve system call entry comments

On 03/08/16 10:45, Andy Lutomirski wrote: > > s/modern/most, perhaps? > > I'm hoping that some day Bionic goes away and gets replaced by musl. > > Of course, musl doesn't always use fast syscalls because it needs a > vdso facility that doesn't currently exist. I'll deal with that > eventually.

Re: [PATCH] x86/entry: Improve system call entry comments

On 03/08/16 02:30, Ingo Molnar wrote: + * + * This is considered a slow path. It is not used by modern libc + * implementations on modern hardware except during process startup. + * >> >> Sadly I believe Android still uses int $0x80 in the upstream version. > > I don't see how

Re: [PATCH] x86/entry: Improve system call entry comments

On March 7, 2016 12:22:28 AM PST, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> Ingo suggested that the comments should explain when the various >> entries are used. This adds these explanations and improves other >> parts of the comments. > >Thanks for doing this, this is really useful! >

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/03/16 12:54, Borislav Petkov wrote: > On Thu, Mar 03, 2016 at 12:22:06PM -0800, H. Peter Anvin wrote: >> The only thing I can think of is that the -8 creates a null pointer that >> terminates a stack trace. > > Probably not needed anymore as print_context_stack()-&g

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/03/16 08:29, Borislav Petkov wrote: > On Thu, Mar 03, 2016 at 07:26:06AM -0800, H. Peter Anvin wrote: >> Why -8? > > GLOBAL(stack_start) > .quad init_thread_union+THREAD_SIZE-8 > ^^^ > > But I don'

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On March 3, 2016 10:35:50 AM PST, "Michael S. Tsirkin" wrote: >On Thu, Mar 03, 2016 at 04:34:53PM +0100, Peter Zijlstra wrote: >> On Thu, Mar 03, 2016 at 04:27:39PM +0100, Ingo Molnar wrote: >> > >> > * Dexuan Cui wrote: >> > >> > > Hi, >> > > My understanding about arch/x86/include/asm/barrier

Re: [tip:core/objtool] x86/asm/decoder: Use explicitly signed chars

On March 3, 2016 8:51:39 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: 19072f23d1d785c093b7f81cb1fb161e7a13ecc0 >Gitweb: >http://git.kernel.org/tip/19072f23d1d785c093b7f81cb1fb161e7a13ecc0 >Author: Josh Poimboeuf >AuthorDate: Wed, 2 Mar 2016 18:39:36 -0600 >Committer: Ingo Moln

Re: [PATCH 2/2] objtool: Support CROSS_COMPILE

On March 2, 2016 6:43:14 PM PST, Stephen Rothwell wrote: >Hi Josh, > >Just a couple of quick comments ... > >On Wed, 2 Mar 2016 18:39:37 -0600 Josh Poimboeuf >wrote: >> >> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile >> index c4f0713..e4a6bd5 100644 >> --- a/tools/objtool/Makefil

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On March 3, 2016 4:28:36 AM PST, Borislav Petkov wrote: >On Wed, Mar 02, 2016 at 02:32:54PM -0800, H. Peter Anvin wrote: >> I'm trying to think of any reason why we couldn't simply have a >symbol >> at the top of the initial stack? Then a simple leaq would suffice;

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On March 2, 2016 2:28:42 PM PST, Borislav Petkov wrote: >On Wed, Mar 02, 2016 at 02:11:51PM -0800, H. Peter Anvin wrote: >> Not sure if we need a reference to _text here. > >Ah, so stack_start is in .ref.data, I guess we can add a __ref_data >marker in vmlinux.lds.S to denot

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/02/16 14:09, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 01:54:50PM -0800, H. Peter Anvin wrote: >> A relocating bootloader is one that doesn't load the kernel at >> CONFIG_PHYSICAL_ADDRESS. The EFI stub is one example. >> >> __START_KERNEL_map is

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/02/16 13:46, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 01:35:09PM -0800, H. Peter Anvin wrote: >> You're not actually testing anything as the real issue is what happens >> with a relocating bootloader. > > Hmm, how would that relocation happen so th

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/02/16 11:50, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 10:39:05AM -0800, H. Peter Anvin wrote: >> Well, we definitely should use %rip-relative addressing if we can. > > Right you are. > >> However, even so I believe this breaks if the kernel is loaded any

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 03/02/16 10:15, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 09:53:28AM -0800, H. Peter Anvin wrote: >> Please explain why we can't use rip-relative addressing in some form... > > We *can* do almost what Brian suggested: > > movqstack_start(

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On March 2, 2016 10:15:56 AM PST, Borislav Petkov wrote: >On Wed, Mar 02, 2016 at 09:53:28AM -0800, H. Peter Anvin wrote: >> Please explain why we can't use rip-relative addressing in some >form... > >We *can* do almost what Brian suggested: > >mo

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On March 2, 2016 8:25:30 AM PST, Borislav Petkov wrote: >On Wed, Mar 02, 2016 at 11:22:30AM -0500, Brian Gerst wrote: >> This should be: movq stack_start(%rip), %rsp > >No it wouldn't. That doesn't work. > >> > + subq$__START_KERNEL_map, %rsp >> >> It would be better to add the offset t

Re: [PATCH v3 9/9] x86/xsaves: Re-enable XSAVES

On March 1, 2016 4:45:41 PM PST, Dave Hansen wrote: >On 03/01/2016 04:34 PM, Yu-cheng Yu wrote: >> On Tue, Mar 01, 2016 at 03:56:12PM -0800, Dave Hansen wrote: >>> On 02/29/2016 09:42 AM, Yu-cheng Yu wrote: - setup_clear_cpu_cap(X86_FEATURE_XSAVES); + if (!config_enabled(CONFIG_X86_64

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On 03/01/16 13:32, Peter Zijlstra wrote: > On Tue, Mar 01, 2016 at 08:23:12PM +, Mathieu Desnoyers wrote: >> I think it's important that user-space fast-paths can quickly >> detect whether the feature is enabled without having to rely on >> always reading a separate cache-line. I've put togethe

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On 02/27/16 16:39, Mathieu Desnoyers wrote: > > Very good points! Would the following interfaces be acceptable ? > > /* This structure needs to be aligned cache line size. */ > struct thread_local_abi { > int32_t cpu_id; /* Aligned on > 32-bit. */ > u

Re: linux-next: build failure after merge of the tip tree

On February 29, 2016 11:28:22 PM PST, Sedat Dilek wrote: >On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar wrote: >> >> * Stephen Rothwell wrote: >> >>> Hi all, >>> >>> After merging the tip tree, today's linux-next build (x86_64 >allmodconfig) >>> failed like this: >>> >>> DESCEND objtool >>> C

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On February 29, 2016 4:41:49 AM PST, Mathieu Desnoyers wrote: > >Agreed that many architectures issue slower instructions when reading >from packed structures, which is unwanted. > And detrimental to atomicity. >Could we require that each field be naturally aligned and require that >they are pl

Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field

On February 27, 2016 11:16:44 AM PST, Dave Hansen wrote: >On 02/27/2016 03:41 AM, Ingo Molnar wrote: >> * Stephen Rothwell wrote: >>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" > wrote: >>>> > > __u64 is okay, "unsigned lo

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On February 27, 2016 10:35:28 AM PST, Linus Torvalds wrote: >On Sat, Feb 27, 2016 at 6:58 AM, Peter Zijlstra >wrote: >> >> Paul's patches have the following structure: >> >> struct thread_local_abi { >> union { >> struct { >> u32 cpu_id; >>

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On February 27, 2016 6:15:01 AM PST, Mathieu Desnoyers wrote: >- On Feb 27, 2016, at 1:24 AM, H. Peter Anvin h...@zytor.com wrote: > >> On 02/26/16 16:40, Mathieu Desnoyers wrote: >>>> >>>> I think it would be a good idea to make this a general pointe

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On 02/26/16 16:40, Mathieu Desnoyers wrote: I think it would be a good idea to make this a general pointer for the kernel to be able to write per thread state to user space, which obviously can't be done with the vDSO. This means the libc per thread startup should query the kernel for the size

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

On February 26, 2016 12:24:15 PM PST, Mathieu Desnoyers wrote: >- On Feb 26, 2016, at 1:01 PM, Thomas Gleixner t...@linutronix.de >wrote: > >> On Fri, 26 Feb 2016, Mathieu Desnoyers wrote: >>> - On Feb 26, 2016, at 11:29 AM, Thomas Gleixner >t...@linutronix.de wrote: >>> > Right. There is

Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field

ut protection >key faults") >Signed-off-by: Dave Hansen >Cc: Stephen Rothwell >Cc: Andrew Morton >Cc: Thomas Gleixner >Cc: Ingo Molnar >Cc: "H. Peter Anvin" >Cc: Peter Zijlstra >Cc: linux-n...@vger.kernel.org >Cc: linux-kernel@vger.kernel.org >Cc: He

Re: [tip:x86/urgent] x86/entry/32: Add an ASM_CLAC to entry_SYSENTER_32

On 02/24/16 21:53, tip-bot for Andy Lutomirski wrote: > Commit-ID: 04d1d281dcfe683a53cddfab8371fc8bb302b069 > Gitweb: http://git.kernel.org/tip/04d1d281dcfe683a53cddfab8371fc8bb302b069 > Author: Andy Lutomirski > AuthorDate: Tue, 23 Feb 2016 13:19:29 -0800 > Committer: Ingo Molnar > Com

Re: [PATCH v4 0/5] getcpu_cache system call for 4.6

On February 23, 2016 8:09:23 PM PST, Mathieu Desnoyers wrote: >- On Feb 23, 2016, at 8:36 PM, H. Peter Anvin h...@zytor.com wrote: > >> On 02/23/2016 03:28 PM, Mathieu Desnoyers wrote: >>> Hi, >>> >>> Here is a patchset implementing a cache for the

Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On February 23, 2016 6:09:19 PM PST, "H. Peter Anvin" wrote: >On February 23, 2016 10:08:06 AM PST, Linus Torvalds > wrote: >>On Tue, Feb 23, 2016 at 9:47 AM, Andy Lutomirski >>wrote: >>> On Feb 23, 2016 1:09 AM, <"tip-bot for Sai Pran

Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

On February 23, 2016 10:08:06 AM PST, Linus Torvalds wrote: >On Tue, Feb 23, 2016 at 9:47 AM, Andy Lutomirski >wrote: >> On Feb 23, 2016 1:09 AM, <"tip-bot for Sai Praneeth >> "@zytor.com> wrote: >> >> Something's wrong with tip-bot. This should say: > >Yeah, there's about 50

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On 02/23/2016 01:49 PM, Eric W. Biederman wrote: > > So I could really respect a patch header line that said: > tree abcdef0123456789...0123456789abcdef > > Where the numbers where the truncated tree hash before and after a patch > was applied. That would seem to give a little bit of extra sanit

Re: [PATCH v4 0/5] getcpu_cache system call for 4.6

On 02/23/2016 03:28 PM, Mathieu Desnoyers wrote: > Hi, > > Here is a patchset implementing a cache for the CPU number of the > currently running thread in user-space. > > Benchmarks comparing this approach to a getcpu based on system call on > ARM show a 44x speedup. They show a 14x speedup on x8

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/23/2016 03:36 PM, Luis R. Rodriguez wrote: > >> 4. the only useful operator on a range is "is address X inside this >>range"; this operator is likely *not* useful for a table, since >>if you have to ever invoke it you are probably doing something very >>wrong. > > kprobe uses it

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/23/2016 03:08 PM, Luis R. Rodriguez wrote: > > OK yes I see the issue now. I've modified this to use const, and > retested the kprobe patch and it works well still. kprobe would not > use LINKTABLE_TEXT, instead it uses its own macro, however users of > LINKTABLE_TEXT would then have const d

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On February 23, 2016 12:35:12 PM PST, Junio C Hamano wrote: >ebied...@xmission.com (Eric W. Biederman) writes: > >> Junio C Hamano writes: >> >>> It is valuable for a testing organization to say "We tested this >>> series on top of version X. We know it works, we have tested on a >>> lot more ha

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On 02/23/16 01:17, Fengguang Wu wrote: > > However we are facing a new situation: in test robot POV, IMHO there > are values to test exactly the same tree as the patch submitter. > Otherwise the robot risks > > - false negative: failing to apply and test some patches > - false positive: sending w

Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/16 13:06, Luis R. Rodriguez wrote: >> >> I think the \n\t is unnecessary. > > Super! I wonder if we we can just use this on s390 as well without it pooping? > I ask as this would set a precedent. > Ask Heike, but I think just ; or \n ought be be fine. I do not know of *any* case where

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > +/** > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if > any > + * > + * @tbl: linker table > + * @func: structure name for the function name we want to call. > + * @args...: arguments to pass to func > + * > + * Examp

Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > With a generic linker tables solution in place we > need a general asm solution for declaring entries > with asm. The first easy target is to cover the C > asm declarations, guard the header file for now > and define a first generic entry push_sect

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > + > +/** > + * DOC: Regular linker linker table constructors > + * > + * Regular constructors are expected to be used for valid linker table > entries. > + * Valid uses of weak entries other than the beginning and is currently > + * untested but s

Re: [RFC v2 0/7] linux: add linker tables

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > This is my v2 of the original linker table work [0], now with > six proof of concepts ports of existing code using custom section > with custom linker script modifications: > > * DEFINE_LINKTABLE_TEXT(char, kprobes); > * DEFINE_LINKTABLE_DATA(

Re: [PATCH 2/5] efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version

On February 12, 2016 3:27:09 AM PST, Matt Fleming wrote: >From: Peter Jones > >Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming >all variable names fit in ASCII. > >Signed-off-by: Peter Jones >Acked-by: Matthew Garrett >Tested-by: "Lee, Chun-Yi" >Signed-off-by: Matt Flem

Re: undefined reference to `efi_call'

On 02/10/16 11:52, Andrew Morton wrote: > On Wed, 10 Feb 2016 16:48:28 +0800 kbuild test robot > wrote: > >> Hi Johannes, >> >> It's probably a bug fix that unveils the link errors. >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: 2178cbc68f3

Re: [PATCH -v2] x86: Add an archinfo dumper module

On 02/04/16 07:22, Borislav Petkov wrote: > Here's v2 with the stuff we talked about, implemented. I've added > 'control_regs' file too so that you can do: > > $ cat /sys/kernel/debug/x86/archinfo/control_regs > CR4: [-|-|SMEP|OSXSAVE|-|-|-|-|OSXMMEXCPT|OSFXSR|-|PGE|MCE|PAE|PSE|-|-|-|-]: > 0x1406

Re: [RFC v1 0/8] x86/init: Linux linker tables

On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote: >> >> Should it be possible to resuse free_init_pages() and/or >> free_reserved_area() only for routines (members in the array in this >> case of a struct of fns) that don't meet our subarch once we're done >> iterating over the routies and know we c

Re: [RFC v1 0/8] x86/init: Linux linker tables

On 01/22/2016 05:44 AM, Michael Matz wrote: > Hi, > > On Thu, 21 Jan 2016, H. Peter Anvin wrote: > >> Something that confuses me is that gcc seems to give these sections the >> "aw" attributes which makes as complain. This might be a gcc bug. > > Workar

Re: [tip:x86/asm] x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32

On January 30, 2016 9:35:57 AM PST, Andy Lutomirski wrote: >On Sat, Jan 30, 2016 at 1:31 AM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> >>>+ if [ "$abi" == "COMMON" -o "$abi" == "64" ]; then >>> >>>+ # COMMON is the same as 64, except that we don't >expect X32 >>> >>>

Re: [tip:x86/asm] x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32

On January 29, 2016 2:19:29 PM PST, Brian Gerst wrote: >On Fri, Jan 29, 2016 at 4:23 PM, H. Peter Anvin wrote: >> On January 29, 2016 3:34:44 AM PST, tip-bot for Andy Lutomirski > wrote: >>>Commit-ID: 32324ce15ea8cb4c8acc28acb2fd36fabf73e9db >>>Gitweb

Re: [tip:x86/asm] x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32

l.sh. > >Signed-off-by: Andy Lutomirski >Cc: Andy Lutomirski >Cc: Borislav Petkov >Cc: Brian Gerst >Cc: Denys Vlasenko >Cc: Frederic Weisbecker >Cc: H. Peter Anvin >Cc: Linus Torvalds >Cc: Peter Zijlstra >Cc: Thomas Gleixner >Link: >http://lkml.kernel

Re: [PATCH 02/31] Add debugger entry points for X86

On 01/28/16 12:22, Jeffrey Merkey wrote: > > Yes sir, I'll add that to the to do list and resubmit after I get all > the comments back for all the changes. It may be important to note > that the arch_kgdb_breakpoint also uses this same syntax and needs > also to be fixed. > That would be a grea

Re: [PATCH 02/31] Add debugger entry points for X86

On 01/28/16 11:46, Jeffrey Merkey wrote: > This patch series adds an export which can be set by system debuggers to > direct the hard lockup and soft lockup detector to trigger a breakpoint > exception and enter a debugger if one is active. It is assumed that if > someone sets this variable, then

Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks

On 01/26/16 00:20, Michael S. Tsirkin wrote: > On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > > Hi hpa, > Any luck getting some feedback on this one? > Yes. What we know so far is that *most* cases it will work, but there are apparently a few corner cases wh

Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 01/25/16 13:12, Luis R. Rodriguez wrote: >> >> Perhaps, but someone would still have to set hardware_subarch. And >> it's hvmlite_bootparams() that does it. > > No, Xen would do it as well, essentially all of hvmlite_bootparams() could be > done in Xen. > Or a stub code. -hpa

Re: [PATCH v3 3/4] x86/efi: print size in binary units in efi_print_memmap

On January 23, 2016 12:29:26 PM PST, One Thousand Gnomes wrote: >All a bit revisionist. Everyone else on the planet was upset about it >because it broke things like calculating bit density because the >prefixes >for the bit capacity are not in metric form. BIPM (keeper of the SI >units) never app

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On January 23, 2016 8:12:23 AM PST, Konrad Rzeszutek Wilk wrote: >On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" >wrote: >>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk >> wrote: >>> >>>>However, this stub belongs in Linux,

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk wrote: > >>However, this stub belongs in Linux, not in the Xen toolstack. That >>way, when the Linux boot protocol is modified, both sides can be >>updated >>accordingly. > >I would add that this idea is borrowed from the EFI stub code th

Re: [RFC v1 0/8] x86/init: Linux linker tables

On 01/22/2016 05:44 AM, Michael Matz wrote: > Hi, > > On Thu, 21 Jan 2016, H. Peter Anvin wrote: > >> Something that confuses me is that gcc seems to give these sections the >> "aw" attributes which makes as complain. This might be a gcc bug. > > Workar

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 16:25, Luis R. Rodriguez wrote: >> >> Basically, if the hardware is enumerable using standard PC mechanisms (PCI, >> ACPI) and doesn't need a special boot flow it should use type 0. > > I can extend the documentation as part of this to be clear. > > I will note though that this still

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 01/21/16 14:25, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk > wrote: >>> Sure, do we know if that ICC compatible? Do we care? There are a >>> series of ICC hacks put in place on ipxe's original solution which >>> I've folded in, it seems that works but if w

Re: [PATCH] base: isa: Remove X86_32 dependency

On 01/21/16 15:43, William Breathitt Gray wrote: > On 01/21/2016 02:40 PM, H. Peter Anvin wrote: >> CONFIG_ISA is mainly used to exclude drivers that are for ISA-specific >> devices. >> >> However, PC/104 is indeed an actual ISA parallel bus, and as you say >>

Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init

Maybe a label attribute would help, I don't know. -hpa

Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init

On 01/21/16 14:56, Borislav Petkov wrote: > > so this is silly: we're basically jumping after the JMP instruction > itself. So that will be the case on !X86_BUG_SYSRET_SS_ATTRS CPUs. > Still a two-byte and now even a useless JMP. > > The right thing to do would be to generate a NOP simply. > OK

Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init

On January 21, 2016 2:14:42 PM PST, Borislav Petkov wrote: >On Wed, Jan 20, 2016 at 02:41:22AM -0800, H. Peter Anvin wrote: >> Ah. What would be even more of a win would be to rebias >> static_cpu_has_bug() so that the fallthrough case is the functional >> one. Easily done by

Re: [PATCH V2] x86: use enum cpuid_leafs instead of magic numbers

On January 21, 2016 1:47:32 PM PST, Borislav Petkov wrote: >On Thu, Jan 21, 2016 at 01:37:36PM -0800, H. Peter Anvin wrote: >> No, you still need to be able to find the beginning of the capability >> array, but the point is that right now it is implicit in that code >that &

Re: [PATCH V2] x86: use enum cpuid_leafs instead of magic numbers

On 01/21/16 13:33, Borislav Petkov wrote: > On Thu, Jan 21, 2016 at 01:25:22PM -0800, H. Peter Anvin wrote: >> See X86_CAPABILITY in head_32.S for example. > > ... so that you can get rid of the offset games at least for > CPUINFO_x86_capability in asm-offsets_32.c? > No,

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 12:05, Luis R. Rodriguez wrote: > >> At least on i386, >> we have to do this in assembly code. > > Neat! How is that order kept? > Right now subarch_entries[] is just an array indexed by subarch number hardcoded in head_32.S. However, if you have a list of (id, target) then you cou

Re: [PATCH V2] x86: use enum cpuid_leafs instead of magic numbers

On 01/21/16 13:21, Borislav Petkov wrote: > On Thu, Jan 21, 2016 at 01:04:57PM -0800, H. Peter Anvin wrote: >> I'm wondering, though, if it wouldn't be better to turn these into >> macros so that they can be used in assembly code. That way the >> definitio

Re: Linux patch disabling AVX when eagerfpu is turned off - possibly not required

On 01/21/16 13:19, Leonid Shatz wrote: > > Thank you all for your feedback and clarifications. That's was my assumption > that SDM was somewhat misleading, but I was not %100 sure about it. It could > be nice, though to see future releases of SDM taking this issue in account. > It will.

Re: [PATCH v2 06/11] lib/vsprintf: introduce %pl to print in human-readable form

On 01/14/16 14:23, Andy Shevchenko wrote: > Introduce a new extension for printing given unsigned long long value in > human-readable form with automatically choosen IEC binary prefix. The value is > passed by reference. Why by reference? That seems to make little sense. The prefix should not in

Re: Linux patch disabling AVX when eagerfpu is turned off - possibly not required

On 01/21/16 13:03, Yu-cheng Yu wrote: > Hello Leonid, > > You are probably right. Let me check this and get back to you. > > Thanks, > Yu-cheng > The hardware people have gotten back to us and this inconsistency in the SDM is unintentional (other places in the SDM has it correctly.) So we shou

Re: [PATCH V2] x86: use enum cpuid_leafs instead of magic numbers

On 01/21/16 03:02, Huaitong Han wrote: > v2:add a commit message. > > Most of magic numbers of x86_capability have been converted to enum > cpuid_leafs, and this patch does update the remaining part. > > Signed-off-by: Huaitong Han Also, the plural of leaf is "leaves". -hpa

Re: [PATCH V2] x86: use enum cpuid_leafs instead of magic numbers

On 01/21/16 03:42, Borislav Petkov wrote: > On Thu, Jan 21, 2016 at 07:02:40PM +0800, Huaitong Han wrote: >> v2:add a commit message. >> >> Most of magic numbers of x86_capability have been converted to enum >> cpuid_leafs, and this patch does update the remaining part. >> >> Signed-off-by: Huaiton

Re: [RFC v1 0/8] x86/init: Linux linker tables

On 12/17/15 20:40, H. Peter Anvin wrote: >> >> const struct >> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0]; >> >> const struct >> foo__attribute__((used,section(".rodata.tbl.tablename.999"))) >> tablena

Re: Linux patch disabling AVX when eagerfpu is turned off - possibly not required

On 01/21/16 12:08, Dave Hansen wrote: > On 01/21/2016 02:33 AM, Leonid Shatz wrote: >> In view of above findings we would like to suggest to double check if >> disabling AVX together with "eagerfpu off" is actually required and is a >> real necessity. It would be helpful to consult with Intel engin

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 11:50, H. Peter Anvin wrote: > > Right... we already do that. > > I don't even think you need to initialize any tables. At least on i386, > we have to do this in assembly code. However, it is just a simple table > walk. :) > It might make more sense to

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 11:46, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote: >>> And that's exactly what HVMlite does. Most of this shim layer is setting >>> up boot_params, after which we jump to standard x86 boot path (i.e. >>> star

Re: [PATCH 2/5] x86/cpufeature: Remove static_cpu_has()

On 01/21/16 11:39, Borislav Petkov wrote: > On Thu, Jan 21, 2016 at 11:04:02AM -0800, Andy Lutomirski wrote: >> Looks good except for the subject line -- you didn't actually remove >> static_cpu_has :) > > Yeah, a proper explanation didn't fit in the commit name line. So I did: > > "x86/cpufeatur

Re: [PATCH] base: isa: Remove X86_32 dependency

On 01/21/16 07:56, William Breathitt Gray wrote: > Many motherboards utilize a LPC to ISA bridge in order to decode > ISA-style port-mapped I/O addresses. This is particularly true for > embedded motherboards supporting the PC/104 bus (a bus specification > derived from ISA). > > These motherboard

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/21/16 05:45, Boris Ostrovsky wrote: >> I don't think the hypervisor should be setting Linux specific boot >> related parameters, the boot ABI should be OS agnostic. IMHO, a small >> shim should be added to Linux in order to set what Linux requires when >> entering from a Xen entry point. For

Re: [PATCH 4/5] x86/alternatives: Add an auxilary section

On 01/21/16 11:07, Borislav Petkov wrote: > On Thu, Jan 21, 2016 at 11:00:03AM -0800, H. Peter Anvin wrote: >> NAK on this being part of .altinstr_replacement (if anything it ought to >> simply be part of .text.init). Otherwise fine. > > You mean .init.text. Brian had it

Re: [PATCH 2/5] x86/cpufeature: Remove static_cpu_has()

On 01/21/16 10:34, Borislav Petkov wrote: > From: Borislav Petkov > > Well, this one doesn't work properly before alternatives have run. And > it was supposed to provide an optimized JMP because the assumption was > that the offset it is jumping to is within a signed byte and thus a > two-byte JM

Re: [PATCH 5/5] x86/alternatives: Discard dynamic check after init

On 01/21/16 10:34, Borislav Petkov wrote: > From: Brian Gerst > > Move the code to do the dynamic check to the altinstr_aux section so > that it is discarded after alternatives have run and a static branch has > been chosen. > > Boris: change it to do TESTB, as hpa suggests. [Also document that

Re: [PATCH 4/5] x86/alternatives: Add an auxilary section

On 01/21/16 10:34, Borislav Petkov wrote: > From: Borislav Petkov > > Add .altinstr_aux for additional instructions which will be used before > and/or during patching. All stuff which needs more sophisticated > patching should go there. See next patch. > > Signed-off-by: Borislav Petkov > --- >

Re: [PATCH 3/5] x86/cpufeature: Get rid of the non-asm goto variant

to be safe, and by now the asm goto-capable gcc is in more wide > use. (Originally the gcc 3.x fallback to pure dynamic didn't exist, > either.)" > > Booy, am I lazy. > Laughed-at-by: H. Peter Anvin ;) -hpa

Re: [PATCH 1/5] x86/cpufeature: Carve out X86_FEATURE_*

On 01/21/16 10:34, Borislav Petkov wrote: > +#ifndef _ASM_X86_REQUIRED_FEATURES_H Why do we have all these include guards at the point of the #include? This is not standard procedure. -hpa

Re: [RFC v1 2/8] tables.h: add linker table support

On January 20, 2016 3:15:48 PM PST, Michael Brown wrote: >>> + * To solve this problem linker tables can be used on Linux, it >enables you to >>> + * always force compiling of select features that one wishes to >avoid bit-rot >>> + * while still enabling you to disable linking feature code into >t

Re: [RFC v1 4/8] x86/init: add linker table support

On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" wrote: >On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >> On 01/20/16 13:33, Luis R. Rodriguez wrote: >>> >>> That's correct for PV and PVH, likewise when qemu is required for >HVM >&

Re: [RFC v1 4/8] x86/init: add linker table support

On 01/20/16 13:33, Luis R. Rodriguez wrote: > > That's correct for PV and PVH, likewise when qemu is required for HVM > qemu could set it. I have the qemu change done but that should only > cover HVM. A common place to set this as well could be the hypervisor, > but currently the hypervisor doesn'

Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init

On 01/20/16 08:04, Borislav Petkov wrote: > On Wed, Jan 20, 2016 at 07:09:39AM -0800, H. Peter Anvin wrote: >> But then you're using testl and get long immediates. >> >> (And the parentheses around boot_cpu_data->x86_capability are redundant.) > > Right. >

Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init

On 01/20/16 07:01, Borislav Petkov wrote: > On Tue, Jan 19, 2016 at 08:02:01PM -0800, H. Peter Anvin wrote: >> ... "i" (1 << (bit & 7)), >> "m" (((const char *)boot_cpu_data->x86_capability)[bit >> 3]) ... > > Nice! &g

Re: [PATCH 6/6] arm64: switch to relative exception tables

On 01/04/2016 10:20 AM, Luck, Tony wrote: >> May I humbly ask why the [Finnish] you don't use the equivalent of the >> x86 _ASM_EXTABLE() macro? In fact, why don't we make that one generic, too? > > I'm messing with that right now (with help from Andy Lutomirski and Boris) to > add different clas

Re: [tip:x86/urgent] x86/entry: Restore traditional SYSENTER calling convention

On 01/04/2016 10:31 AM, Andy Lutomirski wrote: > On Mon, Dec 21, 2015 at 7:10 AM, tip-bot for Andy Lutomirski > wrote: >> Commit-ID: 30bfa7b3488bfb1bb75c9f50a5fcac1832970c60 >> Gitweb: >> http://git.kernel.org/tip/30bfa7b3488bfb1bb75c9f50a5fcac1832970c60 >> Author: Andy Lutomirski >> Au

Re: [PATCH 6/6] arm64: switch to relative exception tables

On 01/04/2016 10:20 AM, Luck, Tony wrote: >> May I humbly ask why the [Finnish] you don't use the equivalent of the >> x86 _ASM_EXTABLE() macro? In fact, why don't we make that one generic, too? > > I'm messing with that right now (with help from Andy Lutomirski and Boris) to > add different clas

Re: [PATCH 0/6] generic relative extable support

support for relative extables to search and sort routines >> alpha/extable: use generic search and sort routines >> s390/extable: use generic search and sort routines >> x86/extable: use generic search and sort routines >> ia64/extable: use generic search and sort rou

Re: [PATCH 6/6] arm64: switch to relative exception tables

On 01/04/2016 06:46 AM, Will Deacon wrote: > On Sun, Jan 03, 2016 at 05:05:57PM +0100, Ard Biesheuvel wrote: >> Instead of using absolute addresses for both the exception location >> and the fixup, use offsets relative to the exception table entry values. >> Not only does this cut the size of the e

Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports

On December 22, 2015 1:56:20 PM PST, Arnd Bergmann wrote: >On Tuesday 22 December 2015, Santosh Shukla wrote: >> } >> >> So I care for /dev/ioport types interface who could do more than byte >> data copy to/from user-space. I tested this patch with little >> modification and could able to run pmd

<    1   2   3   4   5   6   7   8   9   10   >