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 s
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).
>
> I can certain
is 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
>
> Any objections for carrying this through the Xen tree?
Acked-by: Thomas Gleixner
__
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 als
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 leftover
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 t
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.
> &g
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_set_pvti_cpu0_va() pvclock_pvti_cpu0_va()
What on earth does that mean?
Aside of that
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?
> >
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 be overridden by the archi
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
> > an in
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 he
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,
> t
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.
> >
&
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
Acked-by:
h series 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 involve
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
config
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
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__
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
___
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
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
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
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 */
> +#
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 mode(
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
> max_cpus
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 (!smp
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 @@
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
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 patch
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.
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
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.
> > >
On Thu, 6 Jul 2017, kernel test robot wrote:
> commit: 03fa63cc96ab35592e0a7d522b8edbc1e6b02d22 ("x86/time: Initialize
> interrupt mode behind timer init")
> ++++
> || 43436935b7 | 03fa63cc96 |
> ++++
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 repre
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.
> >
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 (&
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 again at resto
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
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 subject
esce a few formats and realign arguments
> o Convert a couple of multiple line printks to single line
>
> Signed-off-by: Joe Perches
Acked-by: Thomas Gleixner
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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.
> >
> > So, let us u
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. An
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 u
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:
> > > >
&g
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
> >
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:
> > > >
&g
Signed-off-by: Thomas Gleixner
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 ---
arch/x86/xen/smp.c |6 -
4 fil
cks 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
Reviewed-by: Thomas Gleixner
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 c
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 struct timespec64, without taking the
>
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
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
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
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.
> > > >
> > > > So m
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
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
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.
> >
>
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)
> > > > }
preparation to refactoring this code area.
>
> Signed-off-by: Michael S. Tsirkin
> Acked-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
d Bergmann
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
k, *flags);
> if (timer->flags == tf)
>return base; // 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 (&qu
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
> >
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 b
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.
> > >
> >
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:
> > >
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.
Tha
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. T
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
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 v
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
Commit-ID: 9d85eb9119f4eeeb48e87adfcd71f752655700e9
Gitweb: http://git.kernel.org/tip/9d85eb9119f4eeeb48e87adfcd71f752655700e9
Author: Thomas Gleixner
AuthorDate: Mon, 12 Dec 2016 11:04:53 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 13 Dec 2016 10:22:39 +0100
x86/smpboot: Make
Commit-ID: ce0d3c0a6fb1422101498ef378c0851dabbbf67f
Gitweb: http://git.kernel.org/tip/ce0d3c0a6fb1422101498ef378c0851dabbbf67f
Author: Thomas Gleixner
AuthorDate: Tue, 14 Jul 2015 22:03:57 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 15 Jul 2015 10:39:17 +0200
genirq: Revert
73 matches
Mail list logo
