On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the pa
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending o
ather see tasklets vanish from the planet completely, but that's
going to be a daring feat. So, grudgingly:
Acked-by: Thomas Gleixner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
From: Sebastian Andrzej Siewior
For spinlocks the type spinlock_t should be used instead of "struct
spinlock".
Use DEFINE_SPINLOCK() and spare the run time initialization
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Link: https://lkml.ke
On Thu, 18 Jul 2019, Dexuan Cui wrote:
>
> The concept of the "overlay page" seems weird, and frankly speaking,
> I don't really understand why the Hyper-V guys invented it, but as far
> as this patch here is concerned, I think the patch is safe and it can
> indeed fix the CPU offlining issue I d
On Thu, 18 Jul 2019, Dexuan Cui wrote:
> > On Thu, 4 Jul 2019, Dexuan Cui wrote:
> > This is the allocation when the CPU is brought online for the first
> > time. So what effect has zeroing at allocation time vs. offlining and
> > potentially receiving IPIs? That allocation is never freed.
> >
> >
Dexuan,
On Thu, 4 Jul 2019, Dexuan Cui wrote:
> When a CPU is being offlined, the CPU usually still receives a few
> interrupts (e.g. reschedule IPIs), after hv_cpu_die() disables the
> HV_X64_MSR_VP_ASSIST_PAGE, so hv_apic_eoi_write() may not write the EOI
> MSR, if the apic_assist field's bit0
On Mon, 17 Jun 2019, Dmitry Safonov wrote:
> @@ -196,7 +196,16 @@ void set_hv_tscchange_cb(void (*cb)(void))
> /* Make sure callback is registered before we write to MSRs */
> wmb();
>
> + /*
> + * As reenlightenment vector is global, there is no difference which
> + * C
On Wed, 12 Jun 2019, Vitaly Kuznetsov wrote:
> Dmitry Safonov writes:
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index 1608050e9df9..0bdd79ecbff8 100644
> > --- a/arch/x86/hyperv/hv_init.c
> > +++ b/arch/x86/hyperv/hv_init.c
> > @@ -91,7 +91,7 @@ EXPORT_SYMBOL_GPL(h
On Fri, 15 Mar 2019, Paolo Bonzini wrote:
> On 22/02/19 11:48, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu
> >
> > The max flush rep count of HvFlushGuestPhysicalAddressList hypercall
> > is equal with how many entries of union hv_gpa_page_range can be populated
> > into the input parame
O-APIC irqs have
> 8-bit APIC id.
This looks good now. Can that be applied independent of the IOMMU stuff or
should this go together. If the latter:
Reviewed-by: Thomas Gleixner
If not, I just queue if for 5.1. Let me know,
Thanks,
tglx
___
On Sun, 14 Oct 2018, Liran Alon wrote:
> > On 13 Oct 2018, at 17:53, lantianyu1...@gmail.com wrote:
> >
> > From: Lan Tianyu
> >
> > This patch is to add wrapper functions for tlb_remote_flush_with_range
> > callback.
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > Change sicne V3:
> > Rem
On Wed, 3 Oct 2018, Andy Lutomirski wrote:
> > On Oct 3, 2018, at 5:01 AM, Vitaly Kuznetsov wrote:
> > Not all Hyper-V hosts support reenlightenment notifications (and, if I'm
> > not mistaken, you need to enable nesting for the VM to get the feature -
> > and most VMs don't have this) so I think
On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> > So if the TSC on CPU1 is slightly behind the TSC on CPU0 then now1 can be
> > smaller than cycle_last. The TSC sync stuff does not catch the small delta
> > for unknown raisins.
On Wed, 19 Sep 2018, Thomas Gleixner wrote:
> On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> > > On Sep 18, 2018, at 3:46 PM, Thomas Gleixner wrote:
> > > On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> > >> Do we do better if we use signed arithmetic for the whole
On Wed, 19 Sep 2018, Rasmus Villemoes wrote:
> On 2018-09-19 00:46, Thomas Gleixner wrote:
> > On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> >>>
> >>
> >> Do we do better if we use signed arithmetic for the whole calculation?
> >> Then a small back
On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> > On Sep 18, 2018, at 3:46 PM, Thomas Gleixner wrote:
> > On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> >> Do we do better if we use signed arithmetic for the whole calculation?
> >> Then a small backwards movement wou
On Tue, 18 Sep 2018, Andy Lutomirski wrote:
> > On Sep 18, 2018, at 12:52 AM, Thomas Gleixner wrote:
> >
> >> On Mon, 17 Sep 2018, John Stultz wrote:
> >>> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> >>> Also, I'm not enti
On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> So if the TSC on CPU1 is slightly behind the TSC on CPU0 then now1 can be
> smaller than cycle_last. The TSC sync stuff does not catch the small delta
> for unknown raisins. I'll go and find that machine and test that again.
Of cour
On Tue, 18 Sep 2018, Peter Zijlstra wrote:
> On Tue, Sep 18, 2018 at 12:41:57PM +0200, Thomas Gleixner wrote:
> > I still have one of the machines which is affected by this.
>
> Are we sure this isn't a load vs rdtsc reorder? Because if I look at the
> current code:
Th
On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> > On Tue, 18 Sep 2018, Peter Zijlstra wrote:
> > > > Your memory serves you right. That's indeed observable on CPUs which
> > > > lack TSC_ADJUST.
> > >
>
On Tue, 18 Sep 2018, Thomas Gleixner wrote:
> On Tue, 18 Sep 2018, Peter Zijlstra wrote:
> > > Your memory serves you right. That's indeed observable on CPUs which
> > > lack TSC_ADJUST.
> >
> > But, if the gtod code can observe this, then why doe
On Tue, 18 Sep 2018, Peter Zijlstra wrote:
> On Tue, Sep 18, 2018 at 09:52:26AM +0200, Thomas Gleixner wrote:
> > On Mon, 17 Sep 2018, John Stultz wrote:
> > > On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> > > > Also, I'm not entirely convinced
On Mon, 17 Sep 2018, John Stultz wrote:
> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> > Also, I'm not entirely convinced that this "last" thing is needed at
> > all. John, what's the scenario under which we need it?
>
> So my memory is probably a bit foggy, but I recall that as we
With the storage array in place it's now trivial to support CLOCK_TAI in
the vdso. Extend the base time storage array and add the update code.
Signed-off-by: Thomas Gleixner
---
V2: Remove the masking trick
arch/x86/entry/vsyscall/vsyscall_gtod.c |4
arch/x86/include/asm/vg
All VDSO clock sources are TSC based and use CLOCKSOURCE_MASK(64). There is
no point in masking with all FF. Get rid of it and enforce the mask in the
sanity checker.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |2 +-
arch/x86/kernel/time.c |6
do_realtime() and do_monotonic() are now the same except for the storage
array index. Hand the index in as an argument and collapse the functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 35 +++
1 file changed, 7 insertions
e and gains a few cycles back.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 81 +--
1 file changed, 21 insertions(+), 60 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -48,16
s well, but I have
no way to test that.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 39 ++-
1 file changed, 7 insertions(+), 32 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -76,9
tions over to use it.
The new storage does not longer use gtod_long_t for seconds depending on 32
or 64 bit compile because this needs to be the full 64bit value even for
32bit when a Y2038 function is added. No point in keeping the distinction
alive in the internal representation.
Signed-off-by: T
le for other clock ids.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 38 ---
1 file changed, 18 insertions(+), 20 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -239,29 +239,27 @@ n
Architectures have extra archdata in the clocksource, e.g. for VDSO
support. There are no sanity checks or general initializations for this
available. Add support for that.
Signed-off-by: Thomas Gleixner
---
include/linux/clocksource.h |5 +
kernel/time/Kconfig |4
do_realtime_coarse() and do_monotonic_coarse() are now the same except for
the storage array index. Hand the index in as an argument and collapse the
functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 20
1 file changed, 4 insertions
Runtime validate the VCLOCK_MODE in clocksource::archdata and disable
VCLOCK if invalid, which disables the VDSO but keeps the system running.
Signed-off-by: Thomas Gleixner
---
V2: Fix the VCLOCK_MAX check
arch/x86/Kconfig |1 +
arch/x86/kernel/time.c | 16
2
The sequence count in vgtod_data is unsigned int, but the call sites use
unsigned long, which is a pointless exercise. Fix the call sites and
replace 'unsigned' with unsinged 'int' while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |
Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime()
implementation, which extended the clockid switch case and added yet
another slightly different copy of the same code.
Especially the extended switch case is problematic as the compiler tends to
generate a jump table which then re
On Fri, 14 Sep 2018, Arnd Bergmann wrote:
> On Fri, Sep 14, 2018 at 2:52 PM Thomas Gleixner wrote:
> A couple of architectures (s390, ia64, riscv, powerpc, arm64)
> implement the vdso as assembler code at the moment, so they
> won't be as easy to consolidate (other than outri
On Fri, 14 Sep 2018, Andy Lutomirski wrote:
> > On Sep 14, 2018, at 7:27 AM, Thomas Gleixner wrote:
> > On Fri, 14 Sep 2018, Andy Lutomirski wrote:
> >> That’s... horrible. In an amazing way. Can you add BUILD_BUG_ON somewhere
> >> to assert that this actually work
On Fri, 14 Sep 2018, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
> > +
> > + if (cs->archdata.vclock_mode >= VCLOCK_MAX) {
>
> It should be '>' as VCLOCK_MAX == VCLOCK_HVCLOCK == 3
Indeed.
Thanks,
tglx
_
On Fri, 14 Sep 2018, Andy Lutomirski wrote:
> > On Sep 14, 2018, at 5:50 AM, Thomas Gleixner wrote:
> >
> > With the storage array in place it's now trivial to support CLOCK_TAI in
> > the vdso. Instead of extending the array to accomodate CLOCK_TAI,
On Fri, 14 Sep 2018, Florian Weimer wrote:
> On 09/14/2018 03:05 PM, Thomas Gleixner wrote:
> > On Fri, 14 Sep 2018, Florian Weimer wrote:
> >
> > > On 09/14/2018 02:50 PM, Thomas Gleixner wrote:
> > > > Matt attempted to add CLOCK_TAI support to the VDSO cl
On Fri, 14 Sep 2018, Florian Weimer wrote:
> On 09/14/2018 02:50 PM, Thomas Gleixner wrote:
> > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime()
> > implementation, which extended the clockid switch case and added yet
> > another slightly different
do_realtime() and do_monotonic() are now the same except for the storage
array index. Hand the index in as an argument and collapse the functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 35 +++
1 file changed, 7 insertions
do_realtime_coarse() and do_monotonic_coarse() are now the same except for
the storage array index. Hand the index in as an argument and collapse the
functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 20
1 file changed, 4 insertions
The sequence count in vgtod_data is unsigned int, but the call sites use
unsigned long, which is a pointless exercise. Fix the call sites and
replace 'unsigned' with unsinged 'int' while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |
le for other clock ids.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 38 ---
1 file changed, 18 insertions(+), 20 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -239,29 +239,27 @@ n
nused
- CLOCK_TAI is id 11 which results in 3 when masked with 0x3
Add the mask to the basetime array lookup and set up the CLOCK_TAI base
time in update_vsyscall().
The performance impact of the mask operation is within the noise.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry
Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime()
implementation, which extended the clockid switch case and added yet
another slightly different copy of the same code.
Especially the extended switch case is problematic as the compiler tends to
generate a jump table which then re
tions over to use it.
The new storage does not longer use gtod_long_t for seconds depending on 32
or 64 bit compile because this needs to be the full 64bit value even for
32bit when a Y2038 function is added. No point in keeping the distinction
alive in the internal representation.
Signed-off-by: T
e and gains a few cycles back.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 81 +--
1 file changed, 21 insertions(+), 60 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -48,16
Runtime validate the VCLOCK_MODE in clocksource::archdata and disable
VCLOCK if invalid, which disables the VDSO but keeps the system running.
Signed-off-by: Thomas Gleixner
---
arch/x86/Kconfig |1 +
arch/x86/kernel/time.c | 16
2 files changed, 17 insertions
Architectures have extra archdata in the clocksource, e.g. for VDSO
support. There are no sanity checks or general initializations for this
available. Add support for that.
Signed-off-by: Thomas Gleixner
---
include/linux/clocksource.h |5 +
kernel/time/Kconfig |4
All VDSO clock sources are TSC based and use CLOCKSOURCE_MASK(64). There is
no point in masking with all FF. Get rid of it and enforce the mask in the
sanity checker.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c |2 +-
arch/x86/kernel/time.c |6
s well, but I have
no way to test that.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/vdso/vclock_gettime.c | 39 ++-
1 file changed, 7 insertions(+), 32 deletions(-)
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -76,9
On Thu, 19 Jul 2018, Tianyu Lan wrote:
> On 7/19/2018 8:05 PM, Thomas Gleixner wrote:
> > You already have the SPDX identifier. So the GPL boilerplate is not really
> > required, unless your legal departement insist on it.
> >
>
> Hi Thomas:
> Thanks fo
On Thu, 19 Jul 2018, Tianyu Lan wrote:
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Hyper-V nested virtualization code.
> + *
> + * Copyright (C) 2018, Microsoft, Inc.
> + *
> + * Author : Lan Tianyu
> + *
> + * This program is free software; you can redistribute it an
On Fri, 6 Jul 2018, Michael Kelley (EOSG) wrote:
> > -Original Message-
> > From: Thomas Gleixner
> > Sent: Friday, July 6, 2018 3:42 AM
> > To: KY Srinivasan
> > Cc: Ingo Molnar ; x...@kernel.org;
> > gre...@linuxfoundation.org; l
On Fri, 6 Jul 2018, Thomas Gleixner wrote:
> On Fri, 6 Jul 2018, KY Srinivasan wrote:
> > >
> > > The problem is that the wreckage is in Linus tree and needs to be fixed
> > > there, i.e. via x86/urgent.
> > >
> > > Now we have the new bits queued
On Fri, 6 Jul 2018, KY Srinivasan wrote:
> >
> > The problem is that the wreckage is in Linus tree and needs to be fixed
> > there, i.e. via x86/urgent.
> >
> > Now we have the new bits queued in x86/hyperv already which collide. So
> > we
> > need to merge x86/urgent into x86/hyperv after applyi
gt; > Author: K. Y. Srinivasan
> > Date: Wed May 16 14:53:31 2018 -0700
> >
> > X86/Hyper-V: Enable IPI enlightenments
> >
> > Hyper-V supports hypercalls to implement IPI; use them.
> >
> > Signed-off-by: K. Y. Srinivasan
> > S
On Tue, 19 Jun 2018, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>
> > On Fri, 15 Jun 2018, Vitaly Kuznetsov wrote:
> >> * Fills in gva_list starting from offset. Returns the number of items
> >> added.
> >> @@ -93,10 +95,19 @@ static vo
On Fri, 15 Jun 2018, Vitaly Kuznetsov wrote:
> * Fills in gva_list starting from offset. Returns the number of items added.
> @@ -93,10 +95,19 @@ static void hyperv_flush_tlb_others(const struct cpumask
> *cpus,
> if (cpumask_equal(cpus, cpu_present_mask)) {
> flush->flags |=
On Mon, 21 May 2018, Tianyu Lan wrote:
KY
> The struct hv_vp_assist_page was defined incorrectly.
> The "vtl_control" should be u64[3], "nested_enlightenments_control"
> should be a u64 and there is 7 reserved bytes following "enlighten_vmentry".
> This patch is to fix it.
>
> Signed-off-by
> >
> > From: "K. Y. Srinivasan"
> >
> > Implement APIC related enlightenments.
> >
> > V2: Addressed comments from Thomas Gleixner
> > and Michael Kelley (EOSG) .
>
> Thomas,
>
> I think I have addressed all your comments;
> let
On Fri, 27 Apr 2018, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Thomas Gleixner
> > Sent: Thursday, April 26, 2018 3:24 PM
> > To: KY Srinivasan
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.k
Michael,
On Thu, 26 Apr 2018, Michael Kelley (EOSG) wrote:
> > -Original Message-
> > From: k...@linuxonhyperv.com
> > Sent: Wednesday, April 25, 2018 11:13 AM
> > To: x...@kernel.org; gre...@linuxfoundation.org;
> > linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; o...@a
On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> From: "K. Y. Srinivasan"
>
> Consolidate the allocation of the hypercall input page.
Again. You can provide the new way of allocation first, then you don't have
to add code first in order to remove it later again.
Thanks,
tglx
_
On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
>
> if (!cpumask_equal(mask, cpu_present_mask)) {
> - ipi_arg->vp_set.format = HV_GENERIC_SET_SPARCE_4K;
> + ipi_arg->vp_set.format = HV_GENERIC_SET_SPARSE_4K;
Please move this patch before the others, so you can us
On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
>
> +struct ipi_arg_ex {
> + u32 vector;
> + u32 reserved;
> + struct hv_vpset vp_set;
Please align that in tabular fashion for easy of reading
u32 vector;
u32 reserved;
struct hv_vps
On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> +static int __send_ipi_mask(const struct cpumask *mask, int vector)
> +{
> + int cur_cpu, vcpu;
> + struct ipi_arg_non_ex **arg;
> + struct ipi_arg_non_ex *ipi_arg;
> + int ret = 1;
So this indicates whether __send_ipi_mask() can
On Wed, 25 Apr 2018, k...@linuxonhyperv.com wrote:
> --- /dev/null
> +++ b/arch/x86/hyperv/hv_apic.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0
Thanks for putting the license identifier in.
> +
> +/*
> + * Hyper-V specific APIC code.
> + *
> + * Copyright (C) 2018, Microsoft, Inc.
On Tue, 30 Jan 2018, Thomas Gleixner wrote:
> On Tue, 30 Jan 2018, Radim Krčmář wrote:
> > 2018-01-29 22:48+0100, Thomas Gleixner:
> > > On Wed, 24 Jan 2018, Radim Krčmář wrote:
> > > > 2018-01-24 14:23+0100, Vitaly Kuznetsov:
> > > > > Hyper-V ree
On Tue, 30 Jan 2018, Radim Krčmář wrote:
> 2018-01-29 22:48+0100, Thomas Gleixner:
> > On Wed, 24 Jan 2018, Radim Krčmář wrote:
> > > 2018-01-24 14:23+0100, Vitaly Kuznetsov:
> > > > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're
>
in case we have L2 nested guests.
> >
> > Signed-off-by: Vitaly Kuznetsov
> > Reviewed-by: Thomas Gleixner
> > ---
>
> Thomas,
>
> I think the expectation is that this series will go through the KVM
> tree. Would you prefer a topic branch?
Is there any depe
On Fri, 19 Jan 2018, Vitaly Kuznetsov wrote:
> kbuild test robot writes:
>
> > Hi Vitaly,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on tip/auto-latest]
> > [also build test WARNING on v4.15-rc8 next-20180118]
> > [cannot apply to tip/x86/core
as assured that
> the fix in on the way.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
y: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Wed, 13 Dec 2017, Vitaly Kuznetsov wrote:
> +static int hv_cpu_die(unsigned int cpu)
> +{
> + struct hv_reenlightenment_control re_ctrl;
> + int i;
> + static DEFINE_SPINLOCK(lock);
> +
> + if (hv_reenlightenment_cb == NULL)
> + return 0;
> +
> + /* Make sure the
On Wed, 13 Dec 2017, Vitaly Kuznetsov wrote:
> +void hyperv_reenlightenment_intr(struct pt_regs *regs)
Lacks __visible and __irq_entry annotations.
Thanks,
tglx
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverpro
On Wed, 13 Dec 2017, Vitaly Kuznetsov wrote:
> This is going to be used from KVM code where we need to get both
> TSC and TSC page value.
>
> When Hyper-V code is compiled out just return rdtsc(), this will allow us
> to avoid ugly ifdefs in non-Hyper-V code.
That's not what the patch implements
by: Vitaly Kuznetsov
Reviewed-by: Thomas Gleixner
> ---
> arch/x86/hyperv/hv_init.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 189a398290db..21f9d53d9f00 100644
> --- a/a
On Fri, 29 Dec 2017, Alexandru Chirvasitu wrote:
> All right, I tried to do some more digging around, in the hope of
> getting as close to the source of the problem as I can.
>
> I went back to the very first commit that went astray for me, 2db1f95
> (which is the only one actually panicking), and
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> >
> > > Attached, but heads up on this: when redirecting the output of lspci
> > >
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Attached, but heads up on this: when redirecting the output of lspci
> -vvv to a text file as root I get
>
> pcilib: sysfs_read_vpd: read failed: Input/output error
>
> I can find bugs filed for various distros to this same effect, but
> haven't
On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
>
> > Attached.
> >
> > I don't have a 4.14 family kernel available at the moment on that
> > machine. What I'm attaching comes from the 4.13 one I was playing
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Attached.
>
> I don't have a 4.14 family kernel available at the moment on that
> machine. What I'm attaching comes from the 4.13 one I was playing with
> yesterday, what with kexec and all.
Good enough. Thanks !
On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
>
> > No; it seems to be tied to this specific issue, and I was seeing even
> > before getting logs just now, whenever I'd start one of the bad
> > kernels in recovery mode
On Thu, 28 Dec 2017, Dexuan Cui wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Thursday, December 28, 2017 03:03
> > > > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> >
> > > > For Linux VM running on Hy
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> No; it seems to be tied to this specific issue, and I was seeing even
> before getting logs just now, whenever I'd start one of the bad
> kernels in recovery mode.
>
> But no, I've never seen that in any other logs, or on any other
> screens outs
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> On Thu, Dec 28, 2017 at 05:10:28PM +0100, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > Actually, it decided to cooperate for just long enough for me to get
> > > the dmesg out. Att
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Actually, it decided to cooperate for just long enough for me to get
> the dmesg out. Attached.
>
> This is from the kernel you asked about: Dou's patch + yours, i.e. the
> latest one in that git log I just sent, booted up with 'apic=debug'.
Ok.
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> On Thu, Dec 28, 2017 at 12:00:47PM +0100, Thomas Gleixner wrote:
> > Ok, lets take a step back. The bisect/kexec attempts led us away from the
> > initial problem which is the machine locking up after login, right?
> >
>
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> Merging the contents of another exchange spawned from the original
> > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > through vector " and a patchset, which
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> On Wed, Dec 20, 2017 at 11:58:57AM +0800, Dou Liyang wrote:
> > At 12/20/2017 08:31 AM, Thomas Gleixner wrote:
> > > > I had never heard of 'bisect' before this casual mention (you might tell
> > > > I am
On Sat, 23 Dec 2017, Dexuan Cui wrote:
> > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > Sent: Friday, December 22, 2017 14:29
> >
> > The output of that precise command run just now on a freshly-compiled
> > copy of that commit is attached.
> >
> > On Fri, Dec 22, 2017 at 09:31:2
the
> --- dividers added by me for clarity):
> --- start of output ---
>
> 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714 is the first bad commit
> commit 2b5175c4fa974b6aa05bbd2ee8d443a8036a1714
> Author: Thomas Gleixner
> Date: Tue Oct 17 09:54:57 2017 +0200
>
> gen
On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner wrote:
> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner
> >> wrote:
> >>
> >> No, syscall that existing
On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner wrote:
> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner
> >> wrote:
> >> > On Wed, 15 Nov 2017, Deepa Dina
On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner wrote:
> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> >> Would this work for everyone?
> >
> > Having extra config switches which are selectable by architectures and
1 - 100 of 173 matches
Mail list logo
