Re: [PATCH V2] x86/Hyper-V: don't allocate clockevent device when synthetic timer is unavailable

ltyker...@gmail.com writes: > From: Tianyu Lan > > Current code initializes clock event data structure for syn timer > even when it's unavailable. Fix it. > > Signed-off-by: Tianyu Lan > --- > Change since v1: > Update title and commit log. > > drivers/hv/hv.c | 15 +-- > 1

Re: [Update PATCH] x86/Hyper-V: Initialize Syn timer clock when it's

ltyker...@gmail.com writes: > From: Tianyu Lan > > Current code initializes clock event data structure for syn timer > even when it's not available. Fix it. > > Signed-off-by: Tianyu Lan > --- > - Fix the wrong title. The new one is ... weird too :-) I think it was supposed to be something

Re: general protection fault in __apic_accept_irq

der/llvm/clang >> 80fee25776c2fb61e74c1ecb1a523375c2500b69) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1095467660 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1752fe0a60 >> >> The bug was bisected to: >> >> comm

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

Peter Zijlstra writes: > > I know you probably can't change the HV interface, but I'm thinking its > rather daft you have to specify a CPU at all for this. The HV can just > pick one and send the notification there, who cares. Generally speaking, hypervisor can't know if the CPU is offline (or

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

Dmitry Safonov writes: > On 6/14/19 11:08 AM, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> @@ -182,7 +182,7 @@ void set_hv_tscchange_cb(void (*cb)(void)) >>> struct hv_reenlightenment_control re_ctrl = { >>>

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

Peter Zijlstra writes: > @@ -182,7 +182,7 @@ void set_hv_tscchange_cb(void (*cb)(void)) > struct hv_reenlightenment_control re_ctrl = { > .vector = HYPERV_REENLIGHTENMENT_VECTOR, > .enabled = 1, > - .target_vp = hv_vp_index[smp_processor_id()] > +

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

Thomas Gleixner writes: > 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

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

gt; Cc: Cathy Avery >> Cc: Haiyang Zhang >> Cc: "H. Peter Anvin" >> Cc: Ingo Molnar >> Cc: "K. Y. Srinivasan" >> Cc: "Michael Kelley (EOSG)" >> Cc: Mohammed Gamal >> Cc: Paolo Bonzini >> Cc: Radim Krčmář >

Re: [PATCH] x86/hyperv: Disable preemption while setting reenlightenment vector

; Cc: "K. Y. Srinivasan" > Cc: "Michael Kelley (EOSG)" > Cc: Mohammed Gamal > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Roman Kagan > Cc: Sasha Levin > Cc: Stephen Hemminger > Cc: Thomas Gleixner > Cc: Vitaly Kuznetsov > > Cc: de...@linuxd

Re: [PATCH v3 1/2] PCI: hv: Replace hv_vp_set with hv_vpset

Maya Nakamura writes: > Remove a duplicate definition of VP set (hv_vp_set) and use the common > definition (hv_vpset) that is used in other places. > > Change the order of the members in struct hv_pcibus_device so that the > declaration of retarget_msi_interrupt_params is the last member.

Re: [PATCH v3 2/2] PCI: hv: Refactor hv_irq_unmask() to use cpumask_to_vpset()

Maya Nakamura writes: > Remove the duplicate implementation of cpumask_to_vpset() and use the > shared implementation. Export hv_max_vp_index, which is required by > cpumask_to_vpset(). > > Apply changes to hv_irq_unmask() based on feedback. > I just noticed an issue with this patch, sorry I've

Re: [RFC PATCH] x86, hyperv: fix kernel panic when kexec on HyperV VM

Kairui Song writes: > When hypercalls is used for sending IPIs, kexec will fail with a kernel > panic like this: > > kexec_core: Starting new kernel > BUG: unable to handle kernel NULL pointer dereference at > PGD 800057995067 P4D 800057995067 PUD 57990067 PMD 0 > Oops:

Re: [PATCH 1/2] PCI: hv: Replace hv_vp_set with hv_vpset

Maya Nakamura writes: > Remove a duplicate definition of VP set (hv_vp_set) and use the common > definition (hv_vpset) that is used in other places. > > Signed-off-by: Maya Nakamura > --- > drivers/pci/controller/pci-hyperv.c | 25 - > 1 file changed, 12 insertions(+),

Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining

Dan Carpenter writes: > On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: >> (I remember Greg disliked when people were tagging patches for stable@ >> themselves, he prefered maintainers deciding if the particular commit >> deserves stable@ or not - but as y

Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining

David Hildenbrand writes: > On 07.01.19 14:44, Vitaly Kuznetsov wrote: >> David Hildenbrand writes: >> ... >>> On 04.01.19 15:19, Vitaly Kuznetsov wrote: >>>>if (start_pfn > has->start_pfn && >>>>

Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining

Sasha Levin writes: > On Mon, Jan 07, 2019 at 02:44:30PM +0100, Vitaly Kuznetsov wrote: >>P.S. I still think about bringing mem_hotplug_begin()/done() to >>hv_balloon but that's going to be a separate discussion, here I want to >>have a small fix backportable to stable. >

Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining

David Hildenbrand writes: > On 04.01.19 15:19, Vitaly Kuznetsov wrote: >> Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use >> 128M. To deal with it we implement partial section onlining by registering >> custom page onlining callback (hv_online_page

[PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining

pages and checks sections instead. But in Hyper-V balloon driver we do PageReserved(pfn_to_page()) check and this is now wrong. Switch to checking online_section_nr() instead. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_balloon.c | 10 ++ 1 file changed, 6 insertions(+), 4

Re: [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files

k...@linuxonhyperv.com writes: > + > +static inline u64 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page > *tsc_pg, > +u64 *cur_tsc) > +{ > + u64 scale, offset; > + u32 sequence; > + > + /* > + * The protocol for reading Hyper-V

RE: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info

's kobj name, >> not >> the slot->number. This patch corrects the netvsc driver, so the VF device >> can be >> successfully paired with synthetic NIC. >> >> Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number") >> Sign

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

Andy Lutomirski writes: > On Thu, Oct 4, 2018 at 9:43 AM Marcelo Tosatti wrote: >> >> On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: >> > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti >> > wrote: >> > > >> > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

Marcelo Tosatti writes: > On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: >> >> There is a very long history of different (hardware) issues Marcelo was >> fighting with and the current code is the survived Frankenstein. > > Right, the code has to

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

Dave Hansen writes: > On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >> It is more than just memmaps (e.g. forking udev process doing memory >> onlining also needs memory) but yes, the main idea is to make the >> onlining synchronous with hotplug. > > That's

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

Michal Hocko writes: > On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote: >> David Hildenbrand writes: >> >> > On 02/10/2018 15:47, Michal Hocko wrote: >> ... >> >> >> >> Why do you need a generic hotplug rule in the first place? Why

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

David Hildenbrand writes: > On 02/10/2018 15:47, Michal Hocko wrote: ... >> >> Why do you need a generic hotplug rule in the first place? Why don't you >> simply provide different set of rules for different usecases? Let users >> decide which usecase they prefer rather than try to be clever

Re: [PATCH 02/16] hv_balloon: Replace spin_is_locked() with lockdep

(!spin_is_locked(_device.ha_lock)); > + lockdep_assert_held(_device.ha_lock); > dm_device.num_pages_onlined++; > } Reviewed-by: Vitaly Kuznetsov However, lockdep_assert_held() is a no-op when !CONFIG_LOCKDEP but this doesn't really matter: hv_page_online_one() is static and it has only

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

Andy Lutomirski writes: >> On Oct 3, 2018, at 2:22 AM, Vitaly Kuznetsov wrote: >> >> Andy Lutomirski writes: >> >>> Hi Vitaly, Paolo, Radim, etc., >>> >> The notification you're talking about exists, it is called >> Reenl

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

Andy Lutomirski writes: > Hi Vitaly, Paolo, Radim, etc., > > On Fri, Sep 14, 2018 at 5:52 AM 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

Re: [patch 02/11] x86/time: Implement clocksource_arch_init()

Thomas Gleixner writes: > 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

Re: [patch 10/11] x86/vdso: Move cycle_last handling into the caller

Thomas Gleixner writes: > Dereferencing gtod->cycle_last all over the place and foing the cycles < > last comparison in the vclock read functions generates horrible code. Doing > it at the call site is much better and gains a few cycles both for TSC and > pvclock. > > Caveat: This adds the

[PATCH] tools: hv: fcopy: set 'error' in case an unknown operation was requested

'error' variable is left uninitialized in case we see an unknown operation. As we don't immediately return and proceed to pwrite() we need to set it to something, HV_E_FAIL sounds good enough. Signed-off-by: Vitaly Kuznetsov --- tools/hv/hv_fcopy_daemon.c | 1 + 1 file changed, 1 insertion

Re: [PATCH] vmbus: don't return values for uninitalized channels

k...@linuxonhyperv.com writes: > From: Stephen Hemminger > > For unsupported device types, the vmbus channel ringbuffer is never > initialized, and therefore reading the sysfs files will return garbage > or cause a kernel OOPS. > > Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info") > >

Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu

"Michael Kelley (EOSG)" writes: > From: Vitaly Kuznetsov Sent: Wednesday, August 1, 2018 > 2:26 AM > >> > I was trying to decide if there are any arguments in favor of one >> > approach vs. the other: a per-cpu flag in memory or checking >> >

Re: [PATCH] vmbus: don't return values for uninitalized channels

-1178,6 +1178,9 @@ static ssize_t vmbus_chan_attr_show(struct kobject > *kobj, > if (!attribute->show) > return -EIO; > > + if (chan->state != CHANNEL_OPENED_STATE) > + return -EINVAL; > + >

Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu

"Michael Kelley (EOSG)" writes: > From: Vitaly Kuznetsov Sent: Tuesday, July 31, 2018 > 4:20 AM >> >> Alternatively, we can get rid of synic_initialized flag altogether: >> hv_synic_init() never fails in the first place but we can always >&

Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu

00644 > --- a/drivers/hv/hyperv_vmbus.h > +++ b/drivers/hv/hyperv_vmbus.h > @@ -202,6 +202,8 @@ enum { > struct hv_per_cpu_context { > void *synic_message_page; > void *synic_event_page; > + bool synic_initialized; > + > /* >* buffer to p

Re: [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc

Yidong Ren writes: >> From: Yidong Ren >> Sent: Monday, July 23, 2018 6:26 PM >> +pcpu_sum = kvmalloc(sizeof(struct netvsc_ethtool_pcpu_stats) * >> +num_present_cpus(), GFP_KERNEL); > > Since there is no plan for CPU hotplug in Hyper-V in short term, it is fine > to use

[PATCH 2/2] x86/hyper-v: check for VP_INVAL in hyperv_flush_tlb_others()

nment") Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/mmu.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index 453d2355cd61..1147e1fed7ff 100644 --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -111,6 +111,11 @@ static void

[PATCH 0/2] x86/hyper-v: cope with VP_INVAL in PV TLB flush code

definitely prepare fixes for it if you think this is needed. Vitaly Kuznetsov (2): x86/hyper-v: check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex() x86/hyper-v: check for VP_INVAL in hyperv_flush_tlb_others() arch/x86/hyperv/mmu.c | 7 +++ 1 file changed, 7

[PATCH 1/2] x86/hyper-v: check cpumask_to_vpset() return value in hyperv_flush_tlb_others_ex()

86/hyper-v: Fix the circular dependency in IPI enlightenment") Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/mmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index 0d90e515ec98..453d2355cd61 100644 --- a/arch/x86/hyperv/mmu.c +++ b/a

Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.

k...@linuxonhyperv.com writes: > From: "K. Y. Srinivasan" > > The IPI hypercalls depend on being able to map the Linux notion of CPU ID > to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides > this mapping. Code for populating this array depends on the IPI functionality. >

Re: [PATCH 0/4] x86/hyper-v: optimize PV IPIs

Vitaly Kuznetsov writes: > Wanpeng Li writes: > >> Hi Vitaly, (fix my reply mess this time) >> On Sat, 23 Jun 2018 at 01:09, Vitaly Kuznetsov wrote: >>> >>> When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_ >>> {L

Re: [PATCH 0/4] x86/hyper-v: optimize PV IPIs

Wanpeng Li writes: > Hi Vitaly, (fix my reply mess this time) > On Sat, 23 Jun 2018 at 01:09, Vitaly Kuznetsov wrote: >> >> When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_ >> {LIST,SPACE} hypercalls when possible" patch Michael suggest

Re: [PATCH 0/4] x86/hyper-v: optimize PV IPIs

Wanpeng Li writes: > Hi Vitaly, (fix my reply mess this time) > On Sat, 23 Jun 2018 at 01:09, Vitaly Kuznetsov wrote: >> >> When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_ >> {LIST,SPACE} hypercalls when possible" patch Michael suggest

[PATCH 3/4] x86/hyper-v: use cheaper HVCALL_SEND_IPI hypercall when possible

When there is no need to send an IPI to a CPU with VP number > 64 we can do the job with fast HVCALL_SEND_IPI hypercall. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_apic.c | 29 - 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/arch/

[PATCH 4/4] x86/hyper-v: trace PV IPI send

Trace Hyper-V PV IPIs the same way we do PV TLB flush. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_apic.c | 4 arch/x86/include/asm/trace/hyperv.h | 15 +++ 2 files changed, 19 insertions(+) diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv

[PATCH 0/4] x86/hyper-v: optimize PV IPIs

parameters through registers). Use that too. This series can collide with my "KVM: x86: hyperv: PV IPI support for Windows guests" series as I rename ipi_arg_non_ex/ipi_arg_ex structures there. Depending on which one gets in first we may need to do tiny adjustments. Vitaly Kuznetso

[PATCH 2/4] x86/hyper-v: use 'fast' hypercall for HVCALL_SEND_IPI

Current Hyper-V TLFS (v5.0b) claims that HvCallSendSyntheticClusterIpi hypercall can't be 'fast' (passing parameters through registers) but apparently this is not true, Windows always uses 'fast' version. We can do the same in Linux too. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv

[PATCH 1/4] x86/hyper-v: implement hv_do_fast_hypercall16

Implement 'Fast' hypercall with two 64-bit input parameter. This is going to be used for HvCallSendSyntheticClusterIpi hypercall. Signed-off-by: Vitaly Kuznetsov --- arch/x86/include/asm/mshyperv.h | 34 ++ 1 file changed, 34 insertions(+) diff --git a/arch/x86

Re: Will the name of hyperv_clocksource_tsc_page or hyperv_clocksource pages change?

Fast TSC calibration failed" error > on their CentOS 7.4（3.10.0-693.11.6.el7) VM. Hi Alma, I think the following upstream commit would help: commit 71c2a2d0a81f096a2932fccb39a500116fece554 Author: Vitaly Kuznetsov Date: Thu Jun 22 18:07:30 2017 +0800 x86/hyperv: Read TSC frequency

[PATCH v2] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

stops us from being equally 'smart' in Linux too. Switch to doing cheaper hypercalls whenever possible. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Michael Kelley --- Changes since v1: - Re-worded comment about the optimization in hyperv_flush_tlb_others() [Thomas Gleixner ] --- arch/x

Re: [PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

KY Srinivasan writes: >> -Original Message- >> From: Michael Kelley (EOSG) >> Sent: Tuesday, June 19, 2018 10:57 AM >> To: Vitaly Kuznetsov ; x...@kernel.org >> Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; KY >> Srinivasan ;

Re: [PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

"Michael Kelley (EOSG)" writes: >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org >> On Behalf >> Of Vitaly Kuznetsov >> Sent: Friday, June 15, 2018 9:30 AM >> To: x...@kernel.org >> Cc: de...@linuxdriverproj

Re: [PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

Thomas Gleixner writes: > 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 >> >&

Re: [PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

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 void hyperv_flush_tlb_others(const struct cpumask >> *cpus, >> if (cpu

[PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible

stops us from being equally 'smart' in Linux too. Switch to doing cheaper hypercalls whenever possible. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/mmu.c | 68 --- 1 file changed, 27 insertions(+), 41 deletions(-) diff --git a/arch/x86/hyp

Re: [PATCH v2] tools: hv: update lsvmbus to be compatible with python3

Olaf Hering writes: > Python3 changed the way how 'print' works. > Adjust the code to a syntax that is understood by python2 and python3. > > Signed-off-by: Olaf Hering What are the odds that we decide to send the same patch on the same day? :-)

[PATCH] Tools: hv: vss: fix loop device detection

: Skip freezing filesystems backed by loop") Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- tools/hv/hv_vss_daemon.c | 65 +--- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_d

[PATCH] tools: hv: lsvmbus: convert to Python3

Use '2to3' tool to make lsvmbus work with both Python2 and Python3. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- tools/hv/lsvmbus | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus index 353e56768df8..c184aa

Re: [PATCH net-next, 2/2] hv_netvsc: Add range checking for rx packet offset and length

Haiyang Zhang writes: > From: Haiyang Zhang > > This patch adds range checking for rx packet offset and length. > It may only happen if there is a host side bug. > > Signed-off-by: Haiyang Zhang > --- >

[PATCH RESEND 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

comes from. Vitaly Kuznetsov (4): hv_balloon: fix printk loglevel hv_balloon: simplify hv_online_page()/hv_page_online_one() hv_balloon: fix bugs in num_pages_onlined accounting hv_balloon: trace post_status drivers/hv/Makefile | 1 + drivers/hv/hv_balloon.c

[PATCH RESEND 3/4] hv_balloon: fix bugs in num_pages_onlined accounting

f8d9aaf3af ("Drivers: hv: balloon: Correctly update onlined page count") Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- drivers/hv/hv_balloon.c | 82 + 1 file changed, 69 insertions(+), 13 deletions(-) diff --git a/drivers/hv

[PATCH RESEND 1/4] hv_balloon: fix printk loglevel

We have a mix of different ideas of which loglevel should be used. Unify on the following: - pr_info() for normal operation - pr_warn() for 'strange' host behavior - pr_err() for all errors. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- drivers/hv/hv_balloon.c | 12 ++---

[PATCH RESEND 2/4] hv_balloon: simplify hv_online_page()/hv_page_online_one()

Instead of doing pfn_to_page() and continuosly casting page to unsigned long just cache the pfn of the page with page_to_pfn(). Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- drivers/hv/hv_balloon.c | 27 +-- 1 file changed, 5 insertions(+), 22 del

[PATCH RESEND 4/4] hv_balloon: trace post_status

Hyper-V balloon driver makes non-trivial calculations to convert Linux's representation of free/used memory to what Hyper-V host expects to see. Add a tracepoint to see what's being sent and where the data comes from. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- drivers/hv/Ma

[PATCH v4 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

without any Hyper-V devices of have a CPU with no assigned channels. Reassign reenlightenment notifications to some other active CPU when the CPU which is assigned to get them goes offline. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Reviewed-by: Thomas Gleixner <t...@linu

[PATCH v4 7/7] x86/kvm: support Hyper-V reenlightenment

-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> --- v3 -> v4: add static to kvm_hyperv_tsc_notifier() [kbuild robot] --- arch/x86/kvm/x86.c | 45 + 1 file changed, 45 insertions(+) diff --git a/arch/

[PATCH v4 6/7] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V

for it in KVM. The only non-trivial change in the patch is in vgettsc(): when updating our gtod copy we now need to get both the clockread and tsc value. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> --- arch/x86/kv

[PATCH v4 3/7] x86/hyper-v: reenlightenment notifications support

specifies EAX:BIT(12) of CPUID:0x4009 as the feature identification bit. The right one to check is EAX:BIT(13) of CPUID:0x4003. I was assured that the fix in on the way. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de>

[PATCH v4 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously

This is going to be used from KVM code where we need to get both TSC and TSC page value. Nobody is supposed to use the function when Hyper-V code is compiled out, just BUG(). Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/hyperv/hv_init.c | 1 + arch/x86/inclu

[PATCH v4 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're not supposed to see many of them. However, it may be important to know that the event has happened in case we have L2 nested guests. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Reviewed-by: Thomas Gleix

[PATCH v4 0/7] x86/kvm/hyperv: stable clocksource for L2 guests when running nested KVM on Hyper-V

clocksource is relatively easy, it is done in PATCH 6 of the series. All the rest is required to support L1 migration when TSC frequency changes, we use a special feature from Hyper-V to do the job. Vitaly Kuznetsov (7): x86/hyper-v: check for required priviliges in hyperv_init() x86/hyper-v: add

[PATCH v4 1/7] x86/hyper-v: check for required priviliges in hyperv_init()

In hyperv_init() we presume we always have access to VP index and hypercall MSRs while according to the specification we should check if we're allowed to access the corresponding MSRs before accessing them. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Reviewed-by: Thomas Gleix

[PATCH] x86/hyper-v: stop suppressing X86_FEATURE_PCID

bits of AddressSpace should be 0 in long mode). The flush hypercalls flush all PCIDs for the specified AddressSpace." With this, PCID can be enabled. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/hyperv/mmu.c | 16 1 file changed, 12 insertions(+), 4 de

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

"Michael Kelley (EOSG)" <michael.h.kel...@microsoft.com> writes: > Vitaly Kuznetsov <vkuzn...@redhat.com> writes: >> >> > "Michael Kelley (EOSG)" <michael.h.kel...@microsoft.com> writes: >> > >> >> On Fri

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

Vitaly Kuznetsov <vkuzn...@redhat.com> writes: > "Michael Kelley (EOSG)" <michael.h.kel...@microsoft.com> writes: > >> On Fri, 19 Jan 2018, Thomas Gleixner wrote: >> >>> >>> You added '#include ' to mshyperv.h which is included in

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

"Michael Kelley (EOSG)" <michael.h.kel...@microsoft.com> writes: > On Fri, 19 Jan 2018, Thomas Gleixner wrote: > >> -Original Message- >> From: Thomas Gleixner [mailto:t...@linutronix.de] >> Sent: Friday, January 19, 2018 11:48 PM >> To

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

Thomas Gleixner <t...@linutronix.de> writes: > On Fri, 19 Jan 2018, Vitaly Kuznetsov wrote: >> kbuild test robot <l...@intel.com> writes: >> >> > Hi Vitaly, >> > >> > Thank you for the patch! Perhaps something to improve: >> > >

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

> [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/x86-kvm-hyperv-stable-clocksorce-for-L2-guests-when-running-nested-KVM-on-Hyper-V/20180119-160814 > con

[PATCH v3 6/7] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V

for it in KVM. The only non-trivial change in the patch is in vgettsc(): when updating our gtod copy we now need to get both the clockread and tsc value. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> --- arch/x86/kv

[PATCH v3 7/7] x86/kvm: support Hyper-V reenlightenment

-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> --- arch/x86/kvm/x86.c | 45 + 1 file changed, 45 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f14e0129c8f5..94f28e6002b2 10064

[PATCH v3 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously

This is going to be used from KVM code where we need to get both TSC and TSC page value. Nobody is supposed to use the function when Hyper-V code is compiled out, just BUG(). Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/hyperv/hv_init.c | 1 + arch/x86/inclu

[PATCH v3 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

without any Hyper-V devices of have a CPU with no assigned channels. Reassign reenlightenment notifications to some other active CPU when the CPU which is assigned to get them goes offline. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- v2-> v3: - Drop spinlock protection from h

[PATCH v3 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're not supposed to see many of them. However, it may be important to know that the event has happened in case we have L2 nested guests. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/hyperv/hv_

[PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

specifies EAX:BIT(12) of CPUID:0x4009 as the feature identification bit. The right one to check is EAX:BIT(13) of CPUID:0x4003. I was assured that the fix in on the way. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- v2 -> v3: - add __visible and __irq_entry [Thomas

[PATCH v3 1/7] x86/hyper-v: check for required priviliges in hyperv_init()

In hyperv_init() we presume we always have access to VP index and hypercall MSRs while according to the specification we should check if we're allowed to access the corresponding MSRs before accessing them. Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> Reviewed-by: Thomas Gleix

[PATCH v3 0/7] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

a special feature from Hyper-V to do the job. Vitaly Kuznetsov (7): x86/hyper-v: check for required priviliges in hyperv_init() x86/hyper-v: add a function to read both TSC and TSC page value simulateneously x86/hyper-v: reenlightenment notifications support x86/hyper-v: redirect

Re: [PATCH v2 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously

Thomas Gleixner <t...@linutronix.de> writes: > 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 w

Re: [PATCH v2 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

Thomas Gleixner <t...@linutronix.de> writes: > 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); >>

Re: [PATCH v2 0/7] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

Vitaly Kuznetsov <vkuzn...@redhat.com> writes: > Paolo Bonzini <pbonz...@redhat.com> writes: >> >> Patches 5-7 are >> >> Acked-by: Paolo Bonzini <pbonz...@redhat.com> >> >> I would appreciate if the Hyper-V folks can provide a topic branch

Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial implementation

Paolo Bonzini <pbonz...@redhat.com> writes: > On 21/12/2017 13:50, Vitaly Kuznetsov wrote: >> I'm back with (somewhat frustrating) results (E5-2603): > > v4 (that would be Broadwell)? > Sorry, v3, actually. Haswell. (the first one supporting vmcs shadowing afaiu).

Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS

Paolo Bonzini <pbonz...@redhat.com> writes: > On 19/12/2017 13:25, Vitaly Kuznetsov wrote: >> >>> At this point in time, I don't think you can just blithely change the >>> virtual VMCS layout and revision number. Existing VMs using the old >>> layout

Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial implementation

Vitaly Kuznetsov <vkuzn...@redhat.com> writes: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> On 18/12/2017 18:17, Vitaly Kuznetsov wrote: >>> The original author of these patches does no longer work at Red Hat, I >>> agreed to take this ov

Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial implementation

Paolo Bonzini <pbonz...@redhat.com> writes: > On 18/12/2017 18:17, Vitaly Kuznetsov wrote: >> The original author of these patches does no longer work at Red Hat, I >> agreed to take this over and send upstream. Here is his original >> description: >> >> &q

Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS

Jim Mattson writes: > At this point in time, I don't think you can just blithely change the > virtual VMCS layout and revision number. Existing VMs using the old > layout and revision number must continue to work on versions of kvm > past this point. You could tie the layout

[PATCH RFC 5/7] KVM: nVMX: add KVM_CAP_HYPERV_ENLIGHTENED_VMCS capability

by KVM as part of enabling KVM_CAP_HYPERV_ENLIGHTENED_VMCS. The version is to be advertised to the nested hypervisor, currently done via a cpuid leaf for Hyper-V. Signed-off-by: Ladi Prosek <lpro...@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/include/a

[PATCH RFC 6/7] KVM: nVMX: add enlightened VMCS state

f enabled. enlightened_vmcs_active is never going to be true if enlightened_vmcs_enabled is not set. Signed-off-by: Ladi Prosek <lpro...@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- arch/x86/kvm/vmx.c | 60 ++ 1 file changed

[PATCH RFC 7/7] KVM: nVMX: implement enlightened VMPTRLD

can result in unexpected behavior." Note that we choose to not modify our VMREAD, VMWRITE, and VMPTRLD handlers. They will not cause any explicit failure but may not have the intended effect. Signed-off-by: Ladi Prosek <lpro...@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com

[PATCH RFC 3/7] KVM: nVMX: add I/O exit ECX, ESI, EDI, EIP vmcs12 fields

From: Ladi Prosek <lpro...@redhat.com> These non-synthetic VMCS fields were not supported by KVM thus far. The layout is according to Hyper-V TLFS 5.0b, the physical encoding according to the Intel SDM. Signed-off-by: Ladi Prosek <lpro...@redhat.com> Signed-off-by: Vitaly Kuzn

[PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS

hances they will clash with future enlightened VMCS versions. Signed-off-by: Ladi Prosek <lpro...@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> --- [Vitaly]: Update VMCS12_REVISION to some new arbitrary number. --- arch/x86/kvm/vmx.c | 321 +++---

  1   2   3   4   5   6   7   8   9   10   >