Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Fri, 17 Nov 2017, Quan Xu wrote: > On 2017-11-16 17:53, Thomas Gleixner wrote: > > That's just plain wrong. We don't want to see any of this PARAVIRT crap in > > anything outside the architecture/hypervisor interfacing code which really > > needs it. > > > > T

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Quan Xu wrote: > On 2017-11-16 06:03, Thomas Gleixner wrote: > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, > struct cpuidle_driver *drv, >     targ

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Quan Xu wrote: > On 2017-11-16 16:45, Peter Zijlstra wrote: > > I really have considered this factor, and try my best not to interfere with > scheduler/idle code. > > if irq_timings code is ready, I can use it directly. I think irq_timings > is not an easy task, I'd like to

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Peter Zijlstra wrote: > On Wed, Nov 15, 2017 at 11:03:08PM +0100, Thomas Gleixner wrote: > > If I understand the problem correctly then he wants to avoid the heavy > > lifting in tick_nohz_idle_enter() in the first place, but there is already > >

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Wed, 15 Nov 2017, Peter Zijlstra wrote: > On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote: > > From: Yang Zhang > > > > Implement a generic idle poll which resembles the functionality > > found in arch/. Provide weak arch_cpu_idle_poll function which > > can

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

On Wed, 8 Nov 2017, Joao Martins wrote: > On 11/08/2017 11:06 AM, Thomas Gleixner wrote: > > The only nit-pick I have are the convoluted function names: > > > > pvclock_set_pvti_cpu0_va() pvclock_pvti_cpu0_va() > > > > What on earth does that mean? > >

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

by: Paolo Bonzini <pbonz...@redhat.com> > > > > IOW, the Xen folks are free to pick up the whole series. :) > > > Thank you! > > I guess only x86 maintainers Ack is left - any comments? The only nit-pick I have are the convoluted function names: pvclock_s

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Boris Ostrovsky wrote: > On 08/31/2017 08:00 AM, Thomas Gleixner wrote: > > On Thu, 31 Aug 2017, Juergen Gross wrote: > >>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts > >>> mindlessly. Patch below. > >

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Juergen Gross wrote: > > I've applied it on top of tip:x86/apic and fixed up the merge conflicts > > mindlessly. Patch below. > > > > Juergen, can you please check the result? > > You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations > of the xen specific

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Thomas Gleixner wrote: > Hrm. For some reason I missed to remove these defines after getting rid of > the tracing idt. > > I'll remove that now in tip and pull in the XEN stuff to see what needs to > be done. I pushed out the removal of the trace leftovers. Ta

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Stephen Rothwell wrote: > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may

Re: [Xen-devel] [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)

ies is a pre-cursor to another AMD processor feature called > Secure Encrypted Virtualization (SEV). The support for SEV will build upon > the SME support and will be submitted later. Details on SEV can be found > in the links below. Well done series. Thanks to all people involved, espec

Re: [Xen-devel] [PATCH 2/2] xen: dont fiddle with event channel masking in suspend/resume

On Mon, 17 Jul 2017, Juergen Gross wrote: > Instead of fiddling with masking the event channels during suspend > and resume handling let do the irq subsystem do its job. It will do > the mask and unmask operations as needed. > > Signed-off-by: Juergen Gross <jgr...@suse.com&

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

On Wed, 12 Jul 2017, Thomas Gleixner wrote: > On Mon, 10 Jul 2017, Juergen Gross wrote: > > It is based on suspend/resume framework. The main work to be done > > additionally is to disconnect from the pv-backends at save time and > > connect to the pv-backends

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

On Mon, 10 Jul 2017, Juergen Gross wrote: > On 07/07/17 19:11, Thomas Gleixner wrote: > > On Fri, 7 Jul 2017, Thomas Gleixner wrote: > > > >> On Fri, 7 Jul 2017, Juergen Gross wrote: > >> > >>> Commit bf22ff45bed664aefb5c4e43029057a199b7070c (&

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

On Fri, 7 Jul 2017, Thomas Gleixner wrote: > On Fri, 7 Jul 2017, Juergen Gross wrote: > > > Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid > > unnecessary low level irq function calls") breaks Xen guest > > save/restore handling. > >

Re: [Xen-devel] Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

On Fri, 7 Jul 2017, Juergen Gross wrote: > Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid > unnecessary low level irq function calls") breaks Xen guest > save/restore handling. > > The main problem are the PV devices using Xen event channels as > interrupt sources which are

Re: [Xen-devel] [x86/time] 03fa63cc96: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface -#)

On Thu, 6 Jul 2017, kernel test robot wrote: > commit: 03fa63cc96ab35592e0a7d522b8edbc1e6b02d22 ("x86/time: Initialize > interrupt mode behind timer init") > ++++ > || 43436935b7 | 03fa63cc96 | >

Re: [Xen-devel] [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

On Mon, 3 Jul 2017, Dou Liyang wrote: > At 07/03/2017 03:18 AM, Thomas Gleixner wrote: > > On Fri, 30 Jun 2017, Dou Liyang wrote: > > > > > xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus > > > which initializes interrupt itself. > > >

Re: [Xen-devel] [PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

On Mon, 3 Jul 2017, Dou Liyang wrote: > At 07/03/2017 01:47 AM, Thomas Gleixner wrote: > > On Fri, 30 Jun 2017, Dou Liyang wrote: > > > +/* Init the interrupt delivery mode for the BSP */ > > > +void __init apic_intr_mode_init(void) > > > +{ > > > + sw

Re: [Xen-devel] [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

On Fri, 30 Jun 2017, Dou Liyang wrote: > xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus > which initializes interrupt itself. > > Touching the intr_mode_init causes unexpected results on the system. > > Bypass it in enlighten_pv system. So that's the wrong patch order then.

Re: [Xen-devel] [PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

On Fri, 30 Jun 2017, Dou Liyang wrote: > Add an unconditional x86_init_ops function which defaults to the > standard function and can be overridden by the early platform code. That changelog describes WHAT the patch does, but not WHY. That's useless as we can see WHAT the patch does from the

Re: [Xen-devel] [PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

On Fri, 30 Jun 2017, Dou Liyang wrote: > +static void __init delay_with_tsc(void) > +{ > + unsigned long long start, now; > + unsigned long ticks = jiffies; Please make that unsigned long end = jiffies + 4; ticks really means: number of ticks. But that variable is doing something

Re: [Xen-devel] [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

On Fri, 30 Jun 2017, Dou Liyang wrote: > static inline int apic_force_enable(unsigned long addr) > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index 0601054..9bf7e95 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1198,6 +1198,10

Re: [Xen-devel] [PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

On Fri, 30 Jun 2017, Dou Liyang wrote: > -static int __init apic_intr_mode_select(void) > +static int __init apic_intr_mode_select(int *upmode) > { > /* Check kernel option */ > if (disable_apic) { > @@ -1206,12 +1208,30 @@ static int __init apic_intr_mode_select(void) > if

Re: [Xen-devel] [PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

On Fri, 30 Jun 2017, Dou Liyang wrote: > /* > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 93f0cda..d6721f0 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kernel/smpboot.c > @@ -1347,8 +1347,11 @@ void __init native_smp_prepare_cpus(unsigned int >

Re: [Xen-devel] [PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

On Fri, 30 Jun 2017, Dou Liyang wrote: > +/* Init the interrupt delivery mode for the BSP */ > +void __init apic_intr_mode_init(void) > +{ > + switch (apic_intr_mode_select()) { > + case APIC_PIC: > + apic_printk(APIC_VERBOSE, KERN_INFO > + "Keep in PIC

Re: [Xen-devel] [PATCH v5 01/12] x86/apic: Construct a selector for the interrupt delivery mode

On Fri, 30 Jun 2017, Dou Liyang wrote: > +static int __init apic_intr_mode_select(void) > +{ > + /* Check kernel option */ > + if (disable_apic) { > + pr_info("APIC disabled via kernel command line\n"); > + return APIC_PIC; > + } > + > + /* Check BIOS */ >

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 10:38 AM, Thomas Gleixner wrote: > > /* > > * Sanitize CPU configuration and retrieve the modifier > > * for the initial pgdir entry which will be programmed > > * into CR3. Depends on enabled

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 2:16 AM, Thomas Gleixner wrote: > > Why is this an unconditional function? Isn't the mask simply 0 when the MEM > > ENCRYPT support is disabled? > > I made it unconditional because of the call from head_64.S. I can'

Re: [Xen-devel] [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit set

Re: [Xen-devel] [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +#ifndef pgprot_encrypted > +#define pgprot_encrypted(prot) (prot) > +#endif > + > +#ifndef pgprot_decrypted That looks wrong. It's not decrypted it's rather unencrypted, right? Thanks, tglx

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Fri, 16 Jun 2017, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/mem_encrypt.h > b/arch/x86/include/asm/mem_encrypt.h > index a105796..988b336 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -15,16 +15,24 @@ > > #ifndef __ASSEMBLY__

Re: [Xen-devel] [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit

Re: [Xen-devel] [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be

Re: [Xen-devel] [PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

s larger > > window now makes it rather easy to hit the problem. > > > > The proper solution is to never set the bit in case of Xen. > > > > Signed-off-by: Juergen Gross <jgr...@suse.com> > > Any objections for carrying this through the Xen tree? Acked-by: Th

Re: [Xen-devel] [PATCH linux v3 2/9] x86/acpi: store ACPI ids from MADT for future usage

On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote: So this patch made it's way into Linus tree via XEN w/o an ack or reviewed by from the x86 maintainers. Yes, we were on CC, but it's not that hard to ping the maintainers when they do not respond on a particular patch. The whole series ran under the

Re: [Xen-devel] [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

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 will > > help to inject DWARF unwinding info by objtool later. > >

Re: [Xen-devel] [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

esce a few formats and realign arguments > o Convert a couple of multiple line printks to single line > > Signed-off-by: Joe Perches <j...@perches.com> Acked-by: Thomas Gleixner <t...@linutronix.de> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] cpufreq: Remove cpu hotplug callbacks only if they were initialized

llbacks have not been installed. > > This means that acpi_cpufreq_boost_exit() should only remove them if > acpi_cpufreq_online is positive. Trying to call > cpuhp_remove_state_nocalls(0) will cause a BUG(). > > Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com&

[Xen-devel] [tip:x86/urgent] x86/smpboot: Make logical package management more robust

Commit-ID: 9d85eb9119f4eeeb48e87adfcd71f752655700e9 Gitweb: http://git.kernel.org/tip/9d85eb9119f4eeeb48e87adfcd71f752655700e9 Author: Thomas Gleixner <t...@linutronix.de> AuthorDate: Mon, 12 Dec 2016 11:04:53 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[Xen-devel] [PATCH v2] x86/smpboot: Make logical package management more robust

Petkov <b...@suse.de> Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: sta...@vger.kernel.org --- arch/x86/kernel/apic/apic.c | 15 arch/x86/kernel/cpu/common.c | 24 ++-- arch/x86/kernel/smpboot.c| 51 -

Re: [Xen-devel] [PATCH] x86/smpboot: Make logical package management more robust

On Sat, 10 Dec 2016, Thomas Gleixner wrote: > On Fri, 9 Dec 2016, Boris Ostrovsky wrote: > > On 12/09/2016 06:02 PM, Boris Ostrovsky wrote: > > > On 12/09/2016 05:06 PM, Thomas Gleixner wrote: > > > > On Thu, 8 Dec 2016, Thomas Gleixner wrote: > > >

Re: [Xen-devel] [PATCH] x86/smpboot: Make logical package management more robust

On Fri, 9 Dec 2016, Boris Ostrovsky wrote: > On 12/09/2016 06:02 PM, Boris Ostrovsky wrote: > > On 12/09/2016 05:06 PM, Thomas Gleixner wrote: > > > On Thu, 8 Dec 2016, Thomas Gleixner wrote: > > > > > > Boris, can you please verify if that makes the > >

Re: [Xen-devel] [PATCH] x86/smpboot: Make logical package management more robust

On Fri, 9 Dec 2016, Boris Ostrovsky wrote: > On 12/09/2016 06:00 PM, Thomas Gleixner wrote: > > On Fri, 9 Dec 2016, Boris Ostrovsky wrote: > > > On 12/09/2016 05:06 PM, Thomas Gleixner wrote: > > > > On Thu, 8 Dec 2016, Thomas Gleixner wrote: > > >

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more

On Mon, 14 Nov 2016, Boris Ostrovsky wrote: > On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote: > > > I found out that my domU kernels invoke the 'apic_disable' function > > because CONFIG_X86_MPPARSE was not enabled in my kernel configuration, > > which would cause the 'smp_found_config' bit to be

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more

On Thu, 10 Nov 2016, Boris Ostrovsky wrote: > On 11/10/2016 10:12 AM, Thomas Gleixner wrote: > > On Thu, 10 Nov 2016, Boris Ostrovsky wrote: > >> By firmware you mean ACPI? It is most likely not available to PV guests. > > You either have to provide ACPI or MP tables.

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, 15 Sep 2016, Kyle Huey wrote: Please use proper prefixes for your patch: git-log arch/x86/kernel/cpu/scattered.c will give you the hint: x86/cpufeature: Move some of the scattered feature bits to x86_capability x86/cpufeature: Correct spelling of the HWP_NOTIFY flag and make the

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

On Thu, 15 Sep 2016, Kyle Huey wrote: First of all, please add a cover letter [PATCH 0/N] to your patch series and send it with something which provides proper mail threading. See: git-send-email, quilt > arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for > now. Rename

Re: [Xen-devel] [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

On Mon, 25 Apr 2016, Jan Beulich wrote: > >>> On 22.04.16 at 20:03, wrote: > >> +#define hugepages_supported() cpu_has_pse > >> > > > > Please don't use the cpu_has_* macros anymore, they are going away soon. > > > > In this case it should be static_cpu_has(X86_FEATURE_PSE). >

Re: [Xen-devel] [PATCH v2 1/6] x86/mm/pat: Change PAT to support non-default PAT MSR

On Tue, 22 Mar 2016, Borislav Petkov wrote: > > +static void pat_keep_handoff_state(void) > > Static function, no need for "pat_" prefix. Also, no need for the > kernel-doc comment. I have to disagree. kernel-doc comments are not limited to global functions. I realy prefer kernel-doc style for

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

Boris, On Tue, 14 Jul 2015, Boris Ostrovsky wrote: > On 07/14/2015 04:15 PM, Thomas Gleixner wrote: > > > > The issue here is that all architectures need that protection and just > > > > Xen does irq allocations in cpu_up. > > > > > > > &g

Re: [Xen-devel] [PATCH v3 13/41] x86: reuse asm-generic/barrier.h

in preparation to refactoring this code area. > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > Acked-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 27/41] x86: define __smp_xxx

; > Acked-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

On Fri, 4 Dec 2015, David Vrabel wrote: > On 04/12/15 14:06, David Vrabel wrote: > > On 03/12/15 10:43, David Vrabel wrote: > >> Adding the rtc platform device when there are no legacy irqs (no > >> legacy PIC) causes a conflict with other devices that end up using the > >> same irq number. > > >

Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

On Tue, 8 Dec 2015, Boris Ostrovsky wrote: > On 12/08/2015 04:02 PM, Thomas Gleixner wrote: > > > > --- a/arch/x86/kernel/rtc.c > > > > +++ b/arch/x86/kernel/rtc.c > > > > @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void) > > > > }

Re: [Xen-devel] [PATCH v2] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

On Mon, 16 Nov 2015, Boris Ostrovsky wrote: > Xen expects legacy interrupts to be there (pretty much for the same reason as > Hyper-V does) and with this change arch_probe_nr_irqs() returns zero and no > descriptors are allocated. Right, because everything which has a PIT gets them and everything

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

On Tue, 10 Nov 2015, John Stultz wrote: > On Tue, Nov 10, 2015 at 7:10 AM, Stefano Stabellini > wrote: > > On Tue, 10 Nov 2015, Arnd Bergmann wrote: > >> On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote: > >> > __current_kernel_time64 returns a

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

On Tue, 10 Nov 2015, John Stultz wrote: > I'm sort of objecting to a different issue, where the > __current_kernel_time() implementation probably shouldn't be grabbing > the tk_core.timekeeper directly, and instead should take a passed > pointer to a timekeeper. The vdso/pv_clock usage should have

Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80

; // oops, wrong base timer-flags |= base-cpu // too late We must write timer-flags in one go, otherwise we can fool other cpus. Fixes: bc7a34b8b9eb (timer: Reduce timer migration overhead if disabled) Signed-off-by: Eric Dumazet eduma...@google.com Cc: Thomas Gleixner t...@linutronix.de

Re: [Xen-devel] [PATCH] xen/events: Support event channel rebind on ARM

On Sat, 25 Jul 2015, Julien Grall wrote: +/* + * Events delivered via platform PCI interrupts are always + * routed to vcpu 0 and hence cannot be rebound. + */ +#define xen_support_evtchn_rebind() \ + (!xen_hvm_domain() || xen_have_vector_callback) Make this an inline please. Thanks,

[Xen-devel] [tip:irq/urgent] genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now

Commit-ID: ce0d3c0a6fb1422101498ef378c0851dabbbf67f Gitweb: http://git.kernel.org/tip/ce0d3c0a6fb1422101498ef378c0851dabbbf67f Author: Thomas Gleixner t...@linutronix.de AuthorDate: Tue, 14 Jul 2015 22:03:57 +0200 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Wed, 15 Jul 2015

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

On Tue, 14 Jul 2015, Boris Ostrovsky wrote: Prevent allocation and freeing of interrupt descriptors accross cpu hotplug. This breaks Xen guests that allocate interrupt descriptors in .cpu_up(). And where exactly does XEN allocate those descriptors? Any chance this locking can be moved

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

On Tue, 14 Jul 2015, Boris Ostrovsky wrote: On 07/14/2015 01:32 PM, Thomas Gleixner wrote: On Tue, 14 Jul 2015, Boris Ostrovsky wrote: On 07/14/2015 11:44 AM, Thomas Gleixner wrote: On Tue, 14 Jul 2015, Boris Ostrovsky wrote: Prevent allocation and freeing of interrupt descriptors

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

On Tue, 14 Jul 2015, Boris Ostrovsky wrote: On 07/14/2015 11:44 AM, Thomas Gleixner wrote: On Tue, 14 Jul 2015, Boris Ostrovsky wrote: Prevent allocation and freeing of interrupt descriptors accross cpu hotplug. This breaks Xen guests that allocate interrupt descriptors

Re: [Xen-devel] [PATCH 0/6] x86: reduce paravirtualized spinlock overhead

On Tue, 16 Jun 2015, Juergen Gross wrote: AFAIK there are no outstanding questions for more than one month now. I'd appreciate some feedback or accepting these patches. They are against dead code, which will be gone soon. We switched over to queued locks. Thanks, tglx

Re: [Xen-devel] [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

On Mon, 1 Jun 2015, Jiang Liu wrote: diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c index 9b62f690b0ff..dfa3a5f5b3d3 100644 --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -494,9 +494,8 @@ static int apic_set_affinity(struct irq_data

Re: [Xen-devel] [Patch v2 08/14] genirq: Introduce helper function irq_data_get_affinity_mask()

On Wed, 20 May 2015, Jiang Liu wrote: Introduce helper function irq_data_get_affinity_mask() and irq_get_affinity_mask() to hide implementation details, That patch does way more than introducing the functions. Again: Patch 1: Introduce helpers Patch 2-n: Convert users subsystem wise Thanks,

Re: [Xen-devel] [PATCH V6 01/18] x86: Make page cache mode a real type

On Thu, 22 Jan 2015, Juergen Gross wrote: On 01/22/2015 08:11 AM, Steven Noonan wrote: I notice these two symbols are exported GPL-only. This breaks builds of several out-of-tree non-GPL modules such as the NVIDIA driver, and VMware modules, etc. What is the appropriate code path for

Re: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use int cpu

On Wed, 10 Dec 2014, Joe Perches wrote: As far as I can tell, there's no value indirecting the cpu passed to this function via a void *. Update all the callers and called functions from within clockevents_notify. Aside of that there is no value for this 'notification' function at all. This

Re: [Xen-devel] [PATCH v2] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

On Tue, 13 Jan 2015, Sander Eikelenboom wrote: Monday, January 12, 2015, 4:01:00 PM, you wrote: On 12/01/15 13:39, Jiang Liu wrote: Commit b81975eade8c (x86, irq: Clean up irqdomain transition code) breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke

Re: [Xen-devel] [PATCH v13 10/11] pvqspinlock, x86: Enable PV qspinlock for KVM

On Wed, 29 Oct 2014, Waiman Long wrote: AIM7 XFS Disk Test (no overcommit) kernel JPMReal Time Sys TimeUsr Time - ---- PV ticketlock 25423737.08 98.95 5.44 PV

Re: [Xen-devel] frequent lockups in 3.18rc4

On Fri, 21 Nov 2014, Konrad Rzeszutek Wilk wrote: On Fri, Nov 21, 2014 at 08:51:43PM +0100, Thomas Gleixner wrote: On Fri, 21 Nov 2014, Linus Torvalds wrote: Here's the simplified end result. Again, this is TOTALLY UNTESTED. I compiled it and verified that the code generation looks like