* Juergen Gross wrote:
> On 08/11/17 10:40, Ingo Molnar wrote:
> >
> > * Juergen Gross wrote:
> >
> >>> Plus add a default empty function (which hypervisors can override). This
> >>> avoids
> >>> all the hidden conditions and wrappe
* Juergen Gross wrote:
> > Plus add a default empty function (which hypervisors can override). This
> > avoids
> > all the hidden conditions and wrappery.
>
> Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
> have to add a pre-filled struct with dummy functions and in c
* Juergen Gross wrote:
> Add a new guest_late_init hook to the hypervisor_x86 structure. It
> will replace the current kvm_guest_init() call which is changed to
> make use of the new hook.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/include/asm/hypervisor.h | 11 +++
> arch/x86/
* Thomas Garnier wrote:
> >>*/
> >> - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp)
> >> + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11
> >> + cmpq%r11, (%rsp)
> >> jne 1f
> > This patch seems to add extra overhead to the syscall fast-pa
* Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
>
> Signed-off-by: Thomas Ga
* Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> diff --git a/arch/x86/cryp
* Pavel Machek wrote:
> On Mon 2017-09-25 09:33:42, Ingo Molnar wrote:
> >
> > * Pavel Machek wrote:
> >
> > > > For example, there would be collision with regular user-space mappings,
> > > > right?
> > > > Can local unp
(Cc:-ed more gents involved in kernel/sched/cputime.c work. Full patch quoted
below.)
* Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> paravirt_steal_clock() might be less than this_rq()->p
* Pavel Machek wrote:
> > For example, there would be collision with regular user-space mappings,
> > right?
> > Can local unprivileged users use mmap(MAP_FIXED) probing to figure out
> > where
> > the kernel lives?
>
> Local unpriviledged users can probably get your secret bits using cache
* H. Peter Anvin wrote:
> We do need to consider how we want modules to fit into whatever model we
> choose, though. They can be adjacent, or we could go with a more
> traditional dynamic link model where the modules can be separate, and
> chained together with the main kernel via the GOT.
So
* H. Peter Anvin wrote:
> On 09/22/17 09:32, Ingo Molnar wrote:
> >
> > BTW., I think things improved with ORC because with ORC we have RBP as an
> > extra
> > register and with PIE we lose RBX - so register pressure in code generation
> > is
> >
* Thomas Garnier wrote:
> > 2) we first implement the additional entropy bits that Linus suggested.
> >
> > does this work for you?
>
> Sure, I can look at how feasible that is. If it is, can I send
> everything as part of the same patch set? The additional entropy would
> be enabled for all
* Thomas Garnier wrote:
> On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote:
> >
> > ( Sorry about the delay in answering this. I could blame the delay on the
> > merge
> > window, but in reality I've been procrastinating this is due to the
> > perma
( Sorry about the delay in answering this. I could blame the delay on the merge
window, but in reality I've been procrastinating this is due to the permanent,
non-trivial impact PIE has on generated C code. )
* Thomas Garnier wrote:
> 1) PIE sometime needs two instructions to represent a s
* Thomas Gleixner wrote:
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -586,6 +586,68 @@ static void xen_write_ldt_entry(struct d
> preempt_enable();
> }
>
> +#ifdef CONFIG_X86_64
> +static struct {
> + void (*orig)(void);
> + void (*xen)(void);
> +
* Thomas Garnier wrote:
> With the fix for function tracing, the hackbench results have an
> average of +0.8 to +1.4% (from +8% to +10% before). With a default
> configuration, the numbers are closer to 0.8%.
>
> On the .text size, with gcc 4.9 I see +0.8% on default configuration
> and +1.180%
* Thomas Garnier wrote:
> > > -model=small/medium assume you are on the low 32-bit. It generates
> > > instructions where the virtual addresses have the high 32-bit to be zero.
> >
> > How are these assumptions hardcoded by GCC? Most of the instructions should
> > be
> > relocatable straight
* Thomas Garnier wrote:
> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
> >
> > * Thomas Garnier wrote:
> >
> >> > Do these changes get us closer to being able to build the kernel as truly
> >> > position independent, i.e. to place it
* Thomas Garnier wrote:
> > Do these changes get us closer to being able to build the kernel as truly
> > position independent, i.e. to place it anywhere in the valid x86-64 address
> > space? Or any other advantages?
>
> Yes, PIE allows us to put the kernel anywhere in memory. It will allow
| 1 -
> 12 files changed, 140 insertions(+), 78 deletions(-)
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
t;>
> >> I'd like to get this regression fixed in 4.13.
> >>
> >> In case nobody objects this week I'll just add the patches to the Xen
> >> tree for rc5.
> >
> >
> > As I said before I think .init_mem_mapping() could live in
>
* Thomas Garnier wrote:
> Changes:
> - v2:
>- Add support for global stack cookie while compiler default to fs without
> mcmodel=kernel
>- Change patch 7 to correctly jump out of the identity mapping on kexec
> load
> preserve.
>
> These patches make the changes necessary to
* Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > >
* Daniel Kiper wrote:
> Hey Greg,
>
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch. If anyone has any objections, please let me know.
>
> Why did you skip this patch for 4.11? IMO it should be applied there too.
The thing is, this patch sho
* Tom Lendacky wrote:
> This patch series provides support for AMD's new Secure Memory Encryption
> (SME)
> feature.
I'm wondering, what's the typical performance hit to DRAM access latency when
SME
is enabled?
On that same note, if the performance hit is noticeable I'd expect SME to not
b
* Daniel Kiper wrote:
> -static const struct efi efi_xen __initconst = {
> - .systab = NULL, /* Initialized later. */
> - .runtime_version = 0,/* Initialized later. */
> - .mps = EFI_INVALID_TABLE_ADDR,
> - .acpi
* Juergen Gross wrote:
> When running under Xen as dom0 /dev/mcelog is being registered by Xen
> instead of the normal mcelog driver. Avoid an error message being
> issued by the mcelog driver in this case. Instead issue an informative
> message that Xen has registered the device.
>
> Signed-of
* Andy Lutomirski wrote:
> The kernel has several code paths that read CR3. Most of them assume that
> CR3 contains the PGD's physical address, whereas some of them awkwardly
> use PHYSICAL_PAGE_MASK to mask off low bits.
>
> Add explicit mask macros for CR3 and convert all of the CR3 readers.
* Boris Ostrovsky wrote:
> > xen_mc_issue() does:
> >
> > if ((paravirt_get_lazy_mode() & mode) == 0)
> > xen_mc_flush();
> >
> > I assume the load_cr3() is intended to deal with the case where we're
> > in lazy mode, but we'll still be in lazy mode, right? Or does it
* Jiri Slaby wrote:
> On 04/10/2017, 09:35 PM, Josh Poimboeuf wrote:
> > The code should be in a mergeable state after each patch. If only
> > patches 1-3 were merged, the code would be in an inconsistent state,
> > with some functions having confusing ENTRY/SYM_FUNC_END pairs. That
> > compli
* Juergen Gross wrote:
> > So my suggestion would be: could you delay 75cd32d6093e for a week, and
> > then
> > merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on
> > the
> > first day of the merge window so there shouldn't be any ordering problems.
>
> Okay, that's
* Juergen Gross wrote:
> On 29/03/17 10:59, Ingo Molnar wrote:
> >
> > * Juergen Gross wrote:
> >
> >> On 29/03/17 05:35, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the
* Juergen Gross wrote:
> On 29/03/17 05:35, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the xen-tip tree got a conflict in:
> >
> > arch/x86/xen/enlighten.c
> >
> > between commits:
> >
> > 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86"
* Josh Poimboeuf wrote:
> On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote:
> >
> > * Jiri Slaby wrote:
> >
> > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> > > >
> > > > * Pavel Machek wrote:
> > > >
* Jiri Slaby wrote:
> On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> >
> > * Pavel Machek wrote:
> >
> >> Hi!
> >>
> >>> -ENTRY(saved_rbp) .quad 0
> >>> -ENTRY(saved_rsi) .quad 0
> >>> -ENTRY(saved_rdi)
* Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
> > ENTRY(ftrace_caller)
> > /* save_mcount_regs fills in first two parameters */
> > @@ -184,11 +184,12 @@ GLOBAL(ftrace_epilogue)
> > GLOBAL(ftrace_graph_call)
> > jmp ftrace_stub
> > #endif
> > +S
* Pavel Machek wrote:
> Hi!
>
> > -ENTRY(saved_rbp) .quad 0
> > -ENTRY(saved_rsi) .quad 0
> > -ENTRY(saved_rdi) .quad 0
> > -ENTRY(saved_rbx) .quad 0
> > +SYM_DATA_START(saved_rbp) .quad 0
> > +SYM_DATA_START(saved_rsi) .quad 0
> > +SYM_DATA_START(saved_rdi
* Thomas Garnier wrote:
> On Thu, Mar 16, 2017 at 1:10 AM, Ingo Molnar wrote:
> >
> > Note that asm/fixmap.h is an x86-ism that isn't present in many other
> > architectures, so this hunk will break the build.
> >
> > To make progress with these patche
* Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will allow GDT remapping in the Fixmap sectio
* Jiri Slaby wrote:
> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
> SYM_ALIAS_START -- use where there are two global names for one code
> SYM_LOCAL_FUNC_START -- use for local functions
> SYM_FUNCTION_START -- use for global functions
> SYM_WEAK_FUNC_START -- use f
* h...@zytor.com wrote:
> On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote:
> >> > So how about using macro names that actually show the purpose, instead
> >> > of
> >> > importing all the crappy, historic, essentially randomly chosen debug
> >
* h...@zytor.com wrote:
> On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote:
> >
> >* Thomas Gleixner wrote:
> >
> >> On Wed, 1 Mar 2017, Ingo Molnar wrote:
> >> >
> >> > * Jiri Slaby wrote:
> >> >
> >> &
* Thomas Gleixner wrote:
> On Wed, 1 Mar 2017, Ingo Molnar wrote:
> >
> > * Jiri Slaby wrote:
> >
> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END,
> > > and other macros across x86. When we have all this sorted out, this wi
* Jiri Slaby wrote:
> This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END,
> and other macros across x86. When we have all this sorted out, this will
> help to inject DWARF unwinding info by objtool later.
>
> So, let us use the macros this way:
> * ENTRY -- start of a global
* Paolo Bonzini wrote:
> > Paolo, how stable, non-rebasing are the KVM tree commits?
>
> Whatever ends in linux-next is stable. I have a separate rebasing branch,
> but it's not part of linux-next by design.
Ok, that's nice!
> > Or should we keep Andy's KVM patches together with the GDT patc
* Thomas Garnier wrote:
> > Okay, I guess I will have to wait for it to be integrated to
> > linux-next then. Or would you rather to it after this patch set is
> > added?
>
> Read your summary for the patchset of KVM cleanup, I will wait for it to
> reach
> linux-next to rebase and send the n
* Andy Lutomirski wrote:
> On Wed, Feb 1, 2017 at 1:15 AM, Ingo Molnar wrote:
> >
> > * Thomas Garnier wrote:
> >
> >> This patch makes the GDT remapped pages read-only to prevent corruption.
> >> This change is done only on 64 bit.
> >
&g
* Thomas Garnier wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64 bit.
Please spell '64-bit' consistently through the series. I've seen two variants:
64 bit
64bit
> +/*
> + * The LTR instruction marks the TSS GDT entry as b
v
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: m...@codeblueprint.co.uk
Cc: xen-de...@lists.xenproject.org
Link:
http://lkml.kernel.org/r/1481215471-9639-1-git-send-email-boris.ostrov...@oracl
* Boris Ostrovsky wrote:
> On 12/08/2016 11:33 PM, Ingo Molnar wrote:
> > * Boris Ostrovsky wrote:
> >
> >> The new Xen PVH entry point requires page tables to be setup by the
> >> kernel since it is entered with paging disabled.
> >>
> >
* Boris Ostrovsky wrote:
> The new Xen PVH entry point requires page tables to be setup by the
> kernel since it is entered with paging disabled.
>
> Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
> invoked from both the new Xen entry point and the existing startup_32
>
> should go? I'd like to have at least patch 2 in 4.10, so I could take
> it through the Xen tree.
Sure, both are fine to me:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
this (Xen PVH) patch
> series. Which would leave me with two options: either keep what this patch
> does,
> leaving it as assembly (requires your ack), or have Xen code build the pages
> on
> its own.
If you give it a try in a subsequent patch (please Cc: me) then it's OK to me:
* Boris Ostrovsky wrote:
> On 12/02/2016 04:45 AM, Ingo Molnar wrote:
> > * Boris Ostrovsky wrote:
> >
> >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote:
> >>>
> >>> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:
> >>>> From: M
* Boris Ostrovsky wrote:
> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote:
> >
> >
> > On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:
> >> From: Matt Fleming
> >>
> >> The new Xen PVH entry point requires page tables to be setup by the
> >> kernel since it is entered with paging disabled.
> >>
>
the system.
>
> Signed-off-by: Alex Thorlton
> Suggested-by: Ingo Molnar
> Cc: Russ Anderson
> Cc: David Vrabel
> Cc: Ingo Molnar
> Cc: Juergen Gross
> Cc: Thomas Gleixner
> Cc: "H. Peter Anvin"
> Cc: Denys Vlasenko
> Cc: Boris Ostrovsky
> Cc: x...@k
* Alex Thorlton wrote:
> On systems with sufficiently large e820 tables, and several IOAPICs, it
> is possible for the XENMEM_machine_memory_map callback (and its
> counterpart, XENMEM_memory_map) to attempt to return an e820 table with
> more than 128 entries. This callback adds entries to the
* Paul Gortmaker wrote:
> [Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On
> 14/07/2016 (Thu 20:39) Ingo Molnar wrote:
>
> >
> > * Paul Gortmaker wrote:
> >
> > > > I'll continue testing with the setup_percpu.c change left
* Paul Gortmaker wrote:
> > I'll continue testing with the setup_percpu.c change left out.
>
> Let me know if you want a resend or if you want to just add the
> asm/desc.h locally or ...
So I tried the asm/desc.h but saw other build failures - for now gave up.
Can we do this in a separate patc
* Paul Gortmaker wrote:
> To that end, I have done allmodconfig, allyesconfig and allnoconfig
> for both 32 bit and 64 bit x86 with these changes on the linux-next
> from today, which presumably has an up to date copy of tip in it.
It does, still I get this on allnoconfig with your patches appl
* Andy Lutomirski wrote:
> On Wed, May 25, 2016 at 2:50 AM, David Vrabel wrote:
> > On 24/05/16 23:48, Andy Lutomirski wrote:
> >> In aa1acff356bb ("x86/xen: Probe target addresses in
> >> set_aliased_prot() before the hypercall"), I added an explicit probe
> >> to work around a hypercall issue
* Kani, Toshimitsu wrote:
> Hello,
>
> The following patches fix two x86 PAT issues reported in 4.4 [1][2]. Can
> you please backport them up to 4.4?
Do they apply, build and boot cleanly in that order on top of v4.4, v4.5 and
v4.6?
If yes then:
Acked-by: Ingo Mol
* Peter Zijlstra wrote:
> My motivation was that people keep trying to send patches against the ticket
> lock code... David did just today, and he's not the first.
Yeah, let's just remove dead code ASAP. It's not like it's hard to add (back)
new
code, should the need arise.
Thanks,
* Stefano Stabellini wrote:
> On Tue, 17 May 2016, David Vrabel wrote:
> > On 17/05/16 11:12, Stefano Stabellini wrote:
> > > On Sat, 14 May 2016, Matt Fleming wrote:
> > >> Folks,
> > >>
> > >> Please pull the following branch which contains support for Xen on ARM
> > >> EFI platforms.
> > >>
>
* Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the
> > conflicts are
> > going to be painful! There's very little reason not to carry this kind of
> > commit:
&g
6 tree,
and
Xen is now reintroducing it in the EFI code. Please don't: if you have to do
capability flags then name the flag accordingly to what it does, don't use some
generic catch-all naming that will inevitably cause the kind of problems
paravirt_enabled() caused...
So: NAKed-
IGHMEM. In this setup,
> this code sets UC attribute for accessing RAM in high memory
> range.
>
> Delete this code block as it has been unused for a long time.
>
> Reported-by: kernel test robot
> Link: https://lkml.org/lkml/2016/4/1/608
> Signed-off-by: Toshi Kani
>
* Luis R. Rodriguez wrote:
> The paravirt_enabled() check is going away, the area tossed to
> the kernel on lguest is not zerored out, so ensure lguest force
> disables tboot and apm just in case the kernel file being read might
> have this set for whatever reason.
>
> Signed-off-by: Luis R. Ro
* Luis R. Rodriguez wrote:
> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
>
> These enums should only ever b
* Toshi Kani wrote:
> A Xorg failure on qemu32 was reported as a regression [1] caused by
> 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
> This patch-set fixes the regression.
>
> Negative effects of this regression were two failures [2] in Xorg on
> QEMU with QEMU CPU
* Ingo Molnar wrote:
> * Andy Lutomirski wrote:
>
> > On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
> > wrote:
> > > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski
> > > wrote:
> > >>
> > >> The code in my queue is, litera
* Andy Lutomirski wrote:
> On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
> wrote:
> > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski
> > wrote:
> >>
> >> The code in my queue is, literally:
> >>
> >> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
> >>
* Linus Torvalds wrote:
> On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote:
> >
> > So yes, let's please warn. I'm okay with removing the panic_on_oops
> > thing though. (But if anyone suggests that we should stop OOPSing on
> > bad kernel page faults, I *will* fight back.)
>
> Bad ke
* Andy Lutomirski wrote:
> On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> > These could still be open coded in an inlined fashion, like the
> >> > scheduler usage.
> >>
> >> We coul
* Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN and, for RDMSR, a return value of zero. If
> panic_on_oops is set, then failed unsafe MSR accesses will still
> oops and panic.
>
> To be clear, this type of failure should *not*
* Andy Lutomirski wrote:
> +bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
> + struct pt_regs *regs, int trapnr)
> +{
> + WARN(1, "unsafe MSR access error: RDMSR from 0x%x",
> + (unsigned int)regs->cx);
Please make this WARN_ONCE().
* Andy Lutomirski wrote:
> On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
> >
> > For hard coded platform quirks I'd suggest we add x86_platform.quirks
> > flags. For
> > example the F00F hack for Xen could be done via:
> >
> >
* Luis R. Rodriguez wrote:
> > > > +enum x86_hardware_subarch {
> > > > X86_SUBARCH_PC = 0,
> > > > X86_SUBARCH_LGUEST,
> > > > X86_SUBARCH_XEN,
> > >
> > > No, this is really backwards.
> > >
> > > While I agree that we want to get rid of paravirt_enabled(), we _dont_
* Luis R. Rodriguez wrote:
> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
>
> v2: fix typos
>
> Cc: Andy Sh
* Luis R. Rodriguez wrote:
> On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar wrote:
> >
> > * Andrew Morton wrote:
> >
> >> > There's a catch-22 issue here either way, for instance this rename patch
> >> > has
> >> > been bein
* Stephen Smalley wrote:
> On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
> >Hi All,
> >
> >I just tried to boot with the current linus mergewindow tree under Xen.
> >It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX"
> >option enabled.
> >Disabling it makes the kernel boot f
* Andy Lutomirski wrote:
> > These could still be open coded in an inlined fashion, like the scheduler
> > usage.
>
> We could have a raw_rdmsr for those.
>
> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is
> worth the effort. This isn't a frequent source of bugs
* Peter Zijlstra wrote:
> On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
> > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> > >
> > > Linus, what's your preference?
> >
> > So quite frankly, is there any reason we don&#x
* Linus Torvalds wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> >
> > Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_
* Andy Lutomirski wrote:
> On Sep 20, 2015 5:15 PM, "Linus Torvalds"
> wrote:
> >
> > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> > > access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> >
* Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ON_ONCE and a return of poisoned values (in the
> RDMSR case). We still write a pr_info entry unconditionally for
> debugging.
>
> To be clear, this type of failure should *not* h
* Andy Lutomirski wrote:
> On Thu, Sep 17, 2015 at 12:19 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
> >> turns all rdmsr and wrmsr operations into the safe va
* Andy Lutomirski wrote:
> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
> turns all rdmsr and wrmsr operations into the safe variants without
> any checks that the operations actually succeed.
>
> This is IMO awful: it papers over bugs. In particular, KVM gueests
> migh
* Andrew Morton wrote:
> > There's a catch-22 issue here either way, for instance this rename patch
> > has
> > been being baked for probably 2 releases already but the difficulty has
> > been
> > trying to find the appropriate time to merge it without conflict.
> >
> > If you do it in the
_mmap_wc(dev, vma, cpu_addr, dma_addr, size)
>
> Generated-by: Coccinelle SmPL
> Suggested-by: Ingo Molnar
> Signed-off-by: Luis R. Rodriguez
> ---
> arch/arm/mach-lpc32xx/phy3250.c | 13 ++---
> arch/arm/mach-netx/fb.c | 14 ++---
* Greg KH wrote:
> On Thu, Aug 13, 2015 at 06:38:46PM -0700, Andy Lutomirski wrote:
> > On Thu, Aug 13, 2015 at 5:44 PM, wrote:
> > >
> > > This is a note to let you know that I've just added the patch titled
> > >
> > > x86/ldt: Make modify_ldt synchronous
> >
> > This needs:
> >
> > ht
* Peter Zijlstra wrote:
> On Wed, Aug 12, 2015 at 02:44:52PM -0400, Boris Ostrovsky wrote:
> > On 08/12/2015 02:36 PM, Peter Zijlstra wrote:
> > >On Wed, Aug 12, 2015 at 11:26:41AM -0700, H. Peter Anvin wrote:
> > >>One option might be to do the addition in assembly, i.e.:
> > >>
> > >>"i" (key)
* Willy Tarreau wrote:
> > > + if (!sysctl_modify_ldt) {
> > > + printk_ratelimited(KERN_INFO
> > > + "Denied a call to modify_ldt() from %s[%d] (uid: %d)."
> > > + " Adjust the modify_ldt sysctl if this was not an"
> >
> > Would it really be so difficult
* Willy Tarreau wrote:
> Hi Ingo,
>
> On Wed, Aug 05, 2015 at 10:00:37AM +0200, Ingo Molnar wrote:
> >
> > * Willy Tarreau wrote:
> >
> > > @@ -276,6 +282,15 @@ asmlinkage int sys_modify_ldt(int func, void __user
> > > *ptr,
> >
* Willy Tarreau wrote:
> @@ -276,6 +282,15 @@ asmlinkage int sys_modify_ldt(int func, void __user *ptr,
> {
> int ret = -ENOSYS;
>
> + if (!sysctl_modify_ldt) {
> + printk_ratelimited(KERN_INFO
> + "Denied a call to modify_ldt() from %s[%d] (uid: %d).
* Andy Lutomirski wrote:
> The modify_ldt syscall exposes a large attack surface and is
> unnecessary for modern userspace. Make it optional.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/Kconfig | 17 +
> arch/x86/include/asm
* Bjorn Helgaas wrote:
> > > > Let me know if these are OK or if there are any questions.
> > > >
> > > > [0] http://lkml.kernel.org/r/20150625204703.gc4...@pd.tnic
> > > > [1] http://lkml.kernel.org/r/20150707095012.gq7...@wotan.suse.de
> > >
> > > Ingo,
> > >
> > > Just a friendly reminder.
* Luis R. Rodriguez wrote:
> On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Ingo,
> >
> > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > and they have baked there for a while now. That tree receives 0-da
* David Vrabel wrote:
> On 15/06/15 10:05, Ian Campbell wrote:
> > On Sat, 2015-06-13 at 11:49 +0200, Ingo Molnar wrote:
> >> xen_mm_pin_all()/unpin_all() are used to implement full guest instance
> >> suspend/restore. It's a stop-all method that needs to ite
* Andy Lutomirski 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 OS drivers
> > >
> > > We can obsolete 2), but we have no control over 1)
1 - 100 of 112 matches
Mail list logo
