Re: [Xen-devel] [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > Note this is barely tested. I intend to do more testing of next few days > but i do not have access to all hardware that make use of the mmu_notifier > API. Thanks for doing this. > First 2 patches convert existing

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote: > > My original performance testing was done with an Ubuntu generic > configuration. This configuration has the CONFIG_FUNCTION_TRACER > option which was incompatible with PIE. The tracer failed to replace > the

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov wrote: > > Below is test cases that allocates a lot of page tables and measuare > fork/exit time. (I'm not entirely sure it's the best way to stress the > codepath.) Looks ok to me. Doing a profile (without the

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov wrote: > > In this case we need performance numbers for !PARAVIRT kernel. Yes. > Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be > interesting too for worst case scenario. Actually, I don't think you

Re: [Xen-devel] [PATCH] x86: enable RCU based table free when PARAVIRT

On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov wrote: > > Solve the issue by enabling RCU-based table free mechanism when PARAVIRT > is selected in config. Testing with kernbench doesn't show any notable > performance impact: I wonder if we should just make it

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.13-rc2

On Fri, Jul 21, 2017 at 3:17 AM, Juergen Gross wrote: > drivers/xen/pvcalls-back.c | 1236 > This really doesn't look like a fix. The merge window is over. So I'm not pulling this without way more explanations of why I should.

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > If that's the case, I'd prefer just turning off the format-truncation > (but not overflow) warning with '-Wno-format-trunction". Doing KBUILD_CFLAGS += $(call cc-disable-warnin

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck wrote: > > The hwmon warnings are all about supporting no more than 9,999 sensors > (applesmc) to 999,999,999 sensors (scpi) of a given type. Yeah, I think that's enough. > Easy "fix" would be to replace snprintf() with

[Xen-devel] Lots of new warnings with gcc-7.1.1

[ Very random list of maintainers and mailing lists, at least partially by number of warnings generated by gcc-7.1.1 that is then correlated with the get_maintainers script ] So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1 Which in turn means that my nice clean

Re: [Xen-devel] [GIT PULL] xen: xenfs fixes for 4.9-rc2

On Mon, Oct 24, 2016 at 9:37 AM, David Vrabel wrote: > > I think the changes are trivial and uncontroversial. Hmm. Sadly, they are also buggy. This: if (files->mode & S_IFLNK) { is simply wrong. The correct test for S_IFLNK is to do if

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki wrote: > > The STAO definition document: > > http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf > > requires as to "operate as if that device does not exist", quite literally. Well, first off,

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: > > Shannon Zhao (16): > Xen: ACPI: Hide UART used by Xen So this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy. Should the

Re: [Xen-devel] [GIT PULL] xen: bug fixes for 4.7-rc0

Having upgraded one of my machines to F24, I get a few new warnings during the kernel compile due to a new compiler. Some of them are just annoying and wrong, but one of them points to a real Xen bug: arch/x86/xen/mmu.c:1116:57: warning: array subscript is above array bounds [-Warray-bounds]

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sun, Apr 3, 2016 at 3:07 AM, Borislav Petkov wrote: > > I'm wondering whether making it try to EFAULT correctly is the right > thing to do... We're certainly more conservative if we panic and not > allow some silently failed attempt at recovery which looks successful, > to

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

On Sat, Apr 2, 2016 at 10:13 AM, Andy Lutomirski wrote: > > I also tried a bad wrmsrl at a couple early points. Very very early > it just works with not warning. A little later and it prints the > warning. Ok, that sounds like the correct behavior - I'm sure the very very

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

This patch series looks much nicer than the last one. I assume you tested that the early-trap handling actually worked too? I only looked at the patches.. Ack to it all, Linus ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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, > struct pt_regs *regs, int trapnr) > { > WARN_ONCE(1, "unchecked MSR access

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote: > > A couple of the wrmsr users actually care about performance. These > are the ones involved in context switching and, to a lesser extent, in > switching in and out of guest mode. .. ok, see the crossed emails. I'd

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > None of this insane complicated crap that buys us exactly *nothing*, > and depends on fancy new exception handling support etc etc. Actually, the one _new_ thing we could do is to inst

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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 kernel page faults

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote: > > We could probably remove that check and let custom fixups run early. > I don't see any compelling reason to keep them disabled. That should > probably be a separate change, though. Or we could just use the existing

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote: > > Can you clarify? KVM uses the native version, and the native version > only oopses with this series applied if panic_on_oops is set. Can we please remove that idiocy? There is no reason to panic whatsoever. Seriously.

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Jan 26, 2016 23:51, "Peter Zijlstra" wrote: > > So for a moment it looked like MIPS wanted to equal or surpass Alpha in > this respect. If there is an architecture that I'd expect to try to take the "sucks more" crown, MIPS would be it. They've already done the "worst

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > This is distinct from: That may be distinct, but: > struct foo *x = READ_ONCE(*ptr); > smp_read_barrier_depends(); > x->bar = 5; This case is complete BS. Stop perpetuating it. I already

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 12:10 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: >> >> > struct foo *x = READ_ONCE(*ptr); >> > smp_read_barrier_depends(); >> >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > You might as well just write it as > > struct foo x = READ_ONCE(*ptr); > x->bar = 5; > > because that "smp_read_barrier_depends()" does NOTHING wrt the

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 3:29 PM, Paul E. McKenney wrote: > > No trailing data-dependent read, so agreed, no smp_read_barrier_depends() > needed. That said, I believe that we should encourage rcu_dereference*() > or lockless_dereference() instead of READ_ONCE() for

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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_msr(unsigned int msr) { int err; unsigned long long

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote: >> >> How many msr reads are so critical that the function call >> overhead would matter? > > if anything qualifies it'd be switch_to() and friends. Is there anything else than the FS/GS_BASE thing (possibly hidden

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote: > > In the interest of sanity, I want to drop the "native_", too Yes. I think the only reason it exists is to have that wrapper layer for PV. And that argument just goes away if you just make the non-inline helper

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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). > We still write a pr_info entry unconditionally for debugging. No, this is wrong.

Re: [Xen-devel] Patch x86/ldt: Make modify_ldt synchronous has been added to the 4.1-stable tree

On Fri, Aug 14, 2015 at 12:16 AM, Ingo Molnar mi...@kernel.org wrote: I just sent it to Linus, so barring a catastrophy it should be upstream soon. Well, I just rejected that pull as completely broken, so I guess the catastrophy happened... Or, alternatively, I mis-read the code, which does

Re: [Xen-devel] [PATCH v16 13/14] pvqspinlock: Improve slowpath performance by avoiding cmpxchg

On Wed, Apr 29, 2015 at 11:11 AM, Peter Zijlstra pet...@infradead.org wrote: On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: In the pv_scan_next() function, the slow cmpxchg atomic operation is performed even if the other CPU is not even close to being halted. This extra cmpxchg

Re: [Xen-devel] [RFC PATCH] x86/asm/irq: Don't use POPF but STI

On Tue, Apr 21, 2015 at 5:45 AM, Ingo Molnar mi...@kernel.org wrote: Totally untested and not signed off yet: because we'd first have to make sure (via irq flags debugging) that it's not used in reverse, to re-disable interrupts: Not only might that happen in some place, I *really* doubt that

Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0

On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov kir...@shutemov.name wrote: I'm feeling I miss very basic background on how Xen works, but why does it set _PAGE_GLOBAL on userspace entries? It sounds strange to me. It is definitely strange. I'm guessing that it's some ancient Xen hack for

Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0

On Thu, Feb 19, 2015 at 5:06 AM, David Vrabel david.vra...@citrix.com wrote: The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not dereference pmd outside of the lock during NUMA hinting fault) and specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Feb 11, 2015 3:15 PM, Jeremy Fitzhardinge jer...@goop.org wrote: Right now it needs to be a locked operation to prevent read-reordering. x86 memory ordering rules state that all writes are seen in a globally consistent order, and are globally ordered wrt reads *on the same addresses*, but

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Mon, Feb 9, 2015 at 4:02 AM, Peter Zijlstra pet...@infradead.org wrote: On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: So we have 3 choices, 1. xadd 2. continue with current approach. 3. a read before unlock and also after that. For the truly paranoid we have

Re: [Xen-devel] linux-next: missing merge fix patch for the merge of the xen-tip tree with the arm-soc tree

On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Linus, I have been carrying this merge fix patch for some time that is now needed in your tree: No, it's not. Look more closely. My merge put the dev-archdata.dma_coherent = coherent; line at the top