* [PATCH v2 2/4] x86/kvm: Change print code to use pr_*() format
From: Zhenzhong Duan @ 2019-09-30 12:08 UTC (permalink / raw)
To: linux-kernel
Cc: vkuznets, linux-hyperv, kvm, Zhenzhong Duan, Paolo Bonzini,
Radim Krcmar, Sean Christopherson, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin
In-Reply-To: <1569845340-11884-1-git-send-email-zhenzhong.duan@oracle.com>
pr_*() is preferred than printk(KERN_* ...), after change all the print
in arch/x86/kernel/kvm.c will have "KVM: xxx" style.
No functional change.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krcmar <rkrcmar@redhat.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wanpeng Li <wanpengli@tencent.com>
Cc: Jim Mattson <jmattson@google.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
arch/x86/kernel/kvm.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a4f108d..7b8cf0d 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -7,6 +7,8 @@
* Authors: Anthony Liguori <aliguori@us.ibm.com>
*/
+#define pr_fmt(fmt) "KVM: " fmt
+
#include <linux/context_tracking.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -286,7 +288,7 @@ static void kvm_register_steal_time(void)
return;
wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
- pr_info("kvm-stealtime: cpu %d, msr %llx\n",
+ pr_info("stealtime: cpu %d, msr %llx\n",
cpu, (unsigned long long) slow_virt_to_phys(st));
}
@@ -321,7 +323,7 @@ static void kvm_guest_cpu_init(void)
wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
__this_cpu_write(apf_reason.enabled, 1);
- printk(KERN_INFO"KVM setup async PF for cpu %d\n",
+ pr_info("setup async PF for cpu %d\n",
smp_processor_id());
}
@@ -347,7 +349,7 @@ static void kvm_pv_disable_apf(void)
wrmsrl(MSR_KVM_ASYNC_PF_EN, 0);
__this_cpu_write(apf_reason.enabled, 0);
- printk(KERN_INFO"Unregister pv shared memory for cpu %d\n",
+ pr_info("Unregister pv shared memory for cpu %d\n",
smp_processor_id());
}
@@ -509,7 +511,7 @@ static void kvm_setup_pv_ipi(void)
{
apic->send_IPI_mask = kvm_send_ipi_mask;
apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
- pr_info("KVM setup pv IPIs\n");
+ pr_info("setup pv IPIs\n");
}
static void kvm_smp_send_call_func_ipi(const struct cpumask *mask)
@@ -639,11 +641,11 @@ static void __init kvm_guest_init(void)
!kvm_para_has_hint(KVM_HINTS_REALTIME) &&
kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
smp_ops.send_call_func_ipi = kvm_smp_send_call_func_ipi;
- pr_info("KVM setup pv sched yield\n");
+ pr_info("setup pv sched yield\n");
}
if (cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "x86/kvm:online",
kvm_cpu_online, kvm_cpu_down_prepare) < 0)
- pr_err("kvm_guest: Failed to install cpu hotplug callbacks\n");
+ pr_err("failed to install cpu hotplug callbacks\n");
#else
sev_map_percpu_data();
kvm_guest_cpu_init();
@@ -746,7 +748,7 @@ static __init int kvm_setup_pv_tlb_flush(void)
zalloc_cpumask_var_node(per_cpu_ptr(&__pv_tlb_mask, cpu),
GFP_KERNEL, cpu_to_node(cpu));
}
- pr_info("KVM setup pv remote TLB flush\n");
+ pr_info("setup pv remote TLB flush\n");
}
return 0;
@@ -879,8 +881,8 @@ static void kvm_enable_host_haltpoll(void *i)
void arch_haltpoll_enable(unsigned int cpu)
{
if (!kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) {
- pr_err_once("kvm: host does not support poll control\n");
- pr_err_once("kvm: host upgrade recommended\n");
+ pr_err_once("host does not support poll control\n");
+ pr_err_once("host upgrade recommended\n");
return;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 3/4] xen: Mark "xen_nopvspin" parameter obsolete and map it to "nopvspin"
From: Zhenzhong Duan @ 2019-09-30 12:08 UTC (permalink / raw)
To: linux-kernel
Cc: vkuznets, linux-hyperv, kvm, Zhenzhong Duan, Jonathan Corbet,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <1569845340-11884-1-git-send-email-zhenzhong.duan@oracle.com>
Fix stale description of "xen_nopvspin" as we use qspinlock now.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
Documentation/admin-guide/kernel-parameters.txt | 7 ++++---
arch/x86/xen/spinlock.c | 13 +++++++------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4b956d8..1f0a62f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5303,8 +5303,9 @@
never -- do not unplug even if version check succeeds
xen_nopvspin [X86,XEN]
- Disables the ticketlock slowpath using Xen PV
- optimizations.
+ Disables the qspinlock slowpath using Xen PV optimizations.
+ This parameter is obsoleted by "nopvspin" parameter, which
+ has equivalent effect for XEN platform.
xen_nopv [X86]
Disables the PV optimizations forcing the HVM guest to
@@ -5330,7 +5331,7 @@
as generic guest with no PV drivers. Currently support
XEN HVM, KVM, HYPER_V and VMWARE guest.
- nopvspin [X86,KVM] Disables the qspinlock slow path
+ nopvspin [X86,XEN,KVM] Disables the qspinlock slow path
using PV optimizations which allow the hypervisor to
'idle' the guest on lock contention.
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 6deb490..092a53f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -18,7 +18,6 @@
static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
static DEFINE_PER_CPU(char *, irq_name);
static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest);
-static bool xen_pvspin = true;
static void xen_qlock_kick(int cpu)
{
@@ -68,7 +67,7 @@ void xen_init_lock_cpu(int cpu)
int irq;
char *name;
- if (!xen_pvspin)
+ if (!pvspin)
return;
WARN(per_cpu(lock_kicker_irq, cpu) >= 0, "spinlock on CPU%d exists on IRQ%d!\n",
@@ -93,7 +92,7 @@ void xen_init_lock_cpu(int cpu)
void xen_uninit_lock_cpu(int cpu)
{
- if (!xen_pvspin)
+ if (!pvspin)
return;
unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
@@ -117,9 +116,9 @@ void __init xen_init_spinlocks(void)
/* Don't need to use pvqspinlock code if there is only 1 vCPU. */
if (num_possible_cpus() == 1)
- xen_pvspin = false;
+ pvspin = false;
- if (!xen_pvspin) {
+ if (!pvspin) {
printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
static_branch_disable(&virt_spin_lock_key);
return;
@@ -137,7 +136,9 @@ void __init xen_init_spinlocks(void)
static __init int xen_parse_nopvspin(char *arg)
{
- xen_pvspin = false;
+ pr_notice("\"xen_nopvspin\" is deprecated, please use \"nopvspin\" instead\n");
+ if (xen_domain())
+ pvspin = false;
return 0;
}
early_param("xen_nopvspin", xen_parse_nopvspin);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 4/4] x86/hyperv: Mark "hv_nopvspin" parameter obsolete and map it to "nopvspin"
From: Zhenzhong Duan @ 2019-09-30 12:09 UTC (permalink / raw)
To: linux-kernel
Cc: vkuznets, linux-hyperv, kvm, Zhenzhong Duan, Jonathan Corbet,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <1569845340-11884-1-git-send-email-zhenzhong.duan@oracle.com>
Includes asm/hypervisor.h in order to reference x86_hyper_type.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
Documentation/admin-guide/kernel-parameters.txt | 6 +++++-
arch/x86/hyperv/hv_spinlock.c | 9 +++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1f0a62f..43f922c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1436,6 +1436,10 @@
hv_nopvspin [X86,HYPER_V] Disables the paravirt spinlock optimizations
which allow the hypervisor to 'idle' the
guest on lock contention.
+ This parameter is obsoleted by "nopvspin"
+ parameter, which has equivalent effect for
+ HYPER_V platform.
+
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
@@ -5331,7 +5335,7 @@
as generic guest with no PV drivers. Currently support
XEN HVM, KVM, HYPER_V and VMWARE guest.
- nopvspin [X86,XEN,KVM] Disables the qspinlock slow path
+ nopvspin [X86,XEN,KVM,HYPER_V] Disables the qspinlock slow path
using PV optimizations which allow the hypervisor to
'idle' the guest on lock contention.
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 07f21a0..e00e319 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -12,12 +12,11 @@
#include <linux/spinlock.h>
+#include <asm/hypervisor.h>
#include <asm/mshyperv.h>
#include <asm/paravirt.h>
#include <asm/apic.h>
-static bool __initdata hv_pvspin = true;
-
static void hv_qlock_kick(int cpu)
{
apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
@@ -64,7 +63,7 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
void __init hv_init_spinlocks(void)
{
- if (!hv_pvspin || !apic ||
+ if (!pvspin || !apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
pr_info("PV spinlocks disabled\n");
@@ -82,7 +81,9 @@ void __init hv_init_spinlocks(void)
static __init int hv_parse_nopvspin(char *arg)
{
- hv_pvspin = false;
+ pr_notice("\"hv_nopvspin\" is deprecated, please use \"nopvspin\" instead\n");
+ if (x86_hyper_type == X86_HYPER_MS_HYPERV)
+ pvspin = false;
return 0;
}
early_param("hv_nopvspin", hv_parse_nopvspin);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 0/3] Add a unified parameter "nopvspin"
From: Zhenzhong Duan @ 2019-09-30 12:08 UTC (permalink / raw)
To: linux-kernel; +Cc: vkuznets, linux-hyperv, kvm, Zhenzhong Duan
There are cases folks want to disable spinlock optimization for
debug/test purpose. Xen and hyperv already have parameters "xen_nopvspin"
and "hv_nopvspin" to support that, but kvm doesn't.
The first patch adds that feature to KVM guest with "nopvspin".
For compatibility reason original parameters "xen_nopvspin" and
"hv_nopvspin" are retained and marked obsolete.
v2:
PATCH1: pick the print code change into seperate PATCH2,
updated patch description [Vitaly Kuznetsov]
PATCH2: new patch with print code change [Vitaly Kuznetsov]
PATCH3: add Reviewed-by [Juergen Gross]
Thanks
Zhenzhong
^ permalink raw reply
* Re: [PATCH] x86/hyperv: make vapic support x2apic mode
From: Roman Kagan @ 2019-10-01 9:18 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all@01.org, Michael Kelley, Lan Tianyu, Joerg Roedel,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <201910010607.cwCYMTaB%lkp@intel.com>
On Tue, Oct 01, 2019 at 06:44:08AM +0800, kbuild test robot wrote:
> url: https://github.com/0day-ci/linux/commits/Roman-Kagan/x86-hyperv-make-vapic-support-x2apic-mode/20191001-044238
> config: x86_64-randconfig-e004-201939 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> arch/x86/hyperv/hv_apic.c: In function 'hv_x2apic_read':
> >> arch/x86/hyperv/hv_apic.c:91:10: error: implicit declaration of function 'native_apic_msr_read'; did you mean 'native_apic_icr_read'? [-Werror=implicit-function-declaration]
> return native_apic_msr_read(reg);
> ^~~~~~~~~~~~~~~~~~~~
> native_apic_icr_read
> arch/x86/hyperv/hv_apic.c: In function 'hv_x2apic_write':
> >> arch/x86/hyperv/hv_apic.c:119:3: error: implicit declaration of function 'native_apic_msr_write'; did you mean 'native_apic_icr_write'? [-Werror=implicit-function-declaration]
> native_apic_msr_write(reg, val);
> ^~~~~~~~~~~~~~~~~~~~~
> native_apic_icr_write
> cc1: some warnings being treated as errors
Oops, !CONFIG_X86_X2APIC needs to be handled. Will post v2.
Roman.
^ permalink raw reply
* Re: [PATCH net v3] vsock: Fix a lockdep warning in __vsock_release()
From: Stefano Garzarella @ 2019-10-01 7:28 UTC (permalink / raw)
To: Dexuan Cui
Cc: davem@davemloft.net, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org, stefanha@redhat.com,
gregkh@linuxfoundation.org, arnd@arndb.de, deepa.kernel@gmail.com,
ytht.net@gmail.com, tglx@linutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Michael Kelley, jhansen@vmware.com
In-Reply-To: <1569868998-56603-1-git-send-email-decui@microsoft.com>
On Mon, Sep 30, 2019 at 06:43:50PM +0000, Dexuan Cui wrote:
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning for hyperv and virtio sockets (vmci socket code
> doesn't have the issue) by using lock_sock_nested() when __vsock_release()
> is called recursively:
>
> ============================================
> WARNING: possible recursive locking detected
> 5.3.0+ #1 Not tainted
> --------------------------------------------
> server/1795 is trying to acquire lock:
> ffff8880c5158990 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
>
> but task is already holding lock:
> ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(sk_lock-AF_VSOCK);
> lock(sk_lock-AF_VSOCK);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 2 locks held by server/1795:
> #0: ffff8880c5d05ff8 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0
> #1: ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
>
> stack backtrace:
> CPU: 5 PID: 1795 Comm: server Not tainted 5.3.0+ #1
> Call Trace:
> dump_stack+0x67/0x90
> __lock_acquire.cold.67+0xd2/0x20b
> lock_acquire+0xb5/0x1c0
> lock_sock_nested+0x6d/0x90
> hvs_release+0x10/0x120 [hv_sock]
> __vsock_release+0x24/0xf0 [vsock]
> __vsock_release+0xa0/0xf0 [vsock]
> vsock_release+0x12/0x30 [vsock]
> __sock_release+0x37/0xa0
> sock_close+0x14/0x20
> __fput+0xc1/0x250
> task_work_run+0x98/0xc0
> do_exit+0x344/0xc60
> do_group_exit+0x47/0xb0
> get_signal+0x15c/0xc50
> do_signal+0x30/0x720
> exit_to_usermode_loop+0x50/0xa0
> do_syscall_64+0x24e/0x270
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x7f4184e85f31
>
> Tested-by: Stefano Garzarella <sgarzare@redhat.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
The patch LGTM and and functionally it's the same as the v2 that I tested, so:
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Thanks,
Stefano
>
> Changes in v2:
> Avoid the duplication of code in v1.
> Also fix virtio socket code.
>
>
> Changes in v3:
> Use "lock_sock_nested(sk, level);" -- suggested by Stefano.
> Add Stefano's Tested-by.
>
> net/vmw_vsock/af_vsock.c | 16 ++++++++++++----
> net/vmw_vsock/hyperv_transport.c | 2 +-
> net/vmw_vsock/virtio_transport_common.c | 2 +-
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index ab47bf3ab66e..2ab43b2bba31 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -638,7 +638,7 @@ struct sock *__vsock_create(struct net *net,
> }
> EXPORT_SYMBOL_GPL(__vsock_create);
>
> -static void __vsock_release(struct sock *sk)
> +static void __vsock_release(struct sock *sk, int level)
> {
> if (sk) {
> struct sk_buff *skb;
> @@ -648,9 +648,17 @@ static void __vsock_release(struct sock *sk)
> vsk = vsock_sk(sk);
> pending = NULL; /* Compiler warning. */
>
> + /* The release call is supposed to use lock_sock_nested()
> + * rather than lock_sock(), if a sock lock should be acquired.
> + */
> transport->release(vsk);
>
> - lock_sock(sk);
> + /* When "level" is SINGLE_DEPTH_NESTING, use the nested
> + * version to avoid the warning "possible recursive locking
> + * detected". When "level" is 0, lock_sock_nested(sk, level)
> + * is the same as lock_sock(sk).
> + */
> + lock_sock_nested(sk, level);
> sock_orphan(sk);
> sk->sk_shutdown = SHUTDOWN_MASK;
>
> @@ -659,7 +667,7 @@ static void __vsock_release(struct sock *sk)
>
> /* Clean up any sockets that never were accepted. */
> while ((pending = vsock_dequeue_accept(sk)) != NULL) {
> - __vsock_release(pending);
> + __vsock_release(pending, SINGLE_DEPTH_NESTING);
> sock_put(pending);
> }
>
> @@ -708,7 +716,7 @@ EXPORT_SYMBOL_GPL(vsock_stream_has_space);
>
> static int vsock_release(struct socket *sock)
> {
> - __vsock_release(sock->sk);
> + __vsock_release(sock->sk, 0);
> sock->sk = NULL;
> sock->state = SS_FREE;
>
> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 261521d286d6..c443db7af8d4 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
> struct sock *sk = sk_vsock(vsk);
> bool remove_sock;
>
> - lock_sock(sk);
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> remove_sock = hvs_close_lock_held(vsk);
> release_sock(sk);
> if (remove_sock)
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 5bb70c692b1e..a666ef8fc54e 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -820,7 +820,7 @@ void virtio_transport_release(struct vsock_sock *vsk)
> struct sock *sk = &vsk->sk;
> bool remove_sock = true;
>
> - lock_sock(sk);
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> if (sk->sk_type == SOCK_STREAM)
> remove_sock = virtio_transport_close(vsk);
>
> --
> 2.19.1
>
--
^ permalink raw reply
* Re: [PATCH] Input: hyperv-keyboard: Add the support of hibernation
From: dmitry.torokhov @ 2019-09-30 23:06 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <PU1P153MB0169C315F7F9EBEBED4C7A7DBF820@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Mon, Sep 30, 2019 at 10:09:27PM +0000, Dexuan Cui wrote:
> > From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com>
> > Sent: Friday, September 27, 2019 5:32 PM
> > > ...
> > > pm_wakeup_pending() is tested in a lot of places in the suspend
> > > process and eventually an unintentional keystroke (or mouse movement,
> > > when it comes to the Hyper-V mouse driver drivers/hid/hid-hyperv.c)
> > > causes the whole hibernation process to be aborted. Usually this
> > > behavior is not expected by the user, I think.
> >
> > Why not? If a device is configured as wakeup source, then it activity
> > should wake up the system, unless you disable it.
>
> Generally speaking, I agree, but compared to a physical machine, IMO
> the scenario is a little differnet when it comes to a VM running on Hyper-V:
> on the host there is a window that represents the VM, and the user can
> unintentionally switch the keyboard input focus to the window (or move
> the mouse/cursor over the window) and then the host automatically
> sends some special keystrokes (and mouse events) , and this aborts the
> hibernation process.
>
> And, when it comes to the Hyper-V mouse device, IMO it's easy for the
> user to unintentionally move the mouse after the "hibernation" button
> is clicked. I suppose a physical machine would have the same issue, though.
If waking the machine up by mouse/keyboard activity is not desired in
Hyper-V environment, then simply disable them as wakeup sources.
>
> > > So, I use the notifier to set the flag variable and with it the driver can
> > > know when it should not call pm_wakeup_hard_event().
> >
> > No, please implement hibernation support properly, as notifier + flag is
> > a hack.
>
> The keyboard/mouse driver can avoid the flag by disabling the
> keyboard/mouse event handling, but the problem is that they don't know
> when exactly they should disable the event handling. I think the PM
> notifier is the only way to tell the drivers a hibernation process is ongoing.
Whatever initiates hibernation (in userspace) can adjust wakeup sources
as needed if you want them disabled completely.
>
> Do you think this idea (notifer + disabling event handling) is acceptable?
No, I believe this a hack, that is why I am pushing back on this.
>
> If not, then I'll have to remove the notifer completely, and document this as
> a known issue to the user: when a hibernation process is started, be careful
> to not switch input focus and not touch the keyboard/mouse until the
> hibernation process is finished. :-)
>
> > In this particular case you do not want to have your
> > hv_kbd_resume() to be called in place of pm_ops->thaw() as that is what
> > reenables the keyboard vmbus channel and causes the undesired wakeup
> > events.
>
> This is only part of the issues. Another example: before the
> pm_ops()->freeze()'s of all the devices are called, pm_wakeup_pending()
> is already tested in a lot of places (e.g. in try_to_freeze_tasks ()) in the
> suspend process, and can abort the whole suspend process upon the user's
> unintentional input focus switch, keystroke and mouse movement.
How long is the prepare() phase on your systems? User may wiggle mouse
at any time really, even before the notifier fires up.
>
> > Your vmbus implementation should allow individual drivers to
> > control the set of PM operations that they wish to use, instead of
> > forcing everything through suspend/resume.
> >
> > Dmitry
>
> Since the devices are pure software-emulated devices, no PM operation was
> supported in the past, and now suspend/resume are the only two PM operations
> we're going to support. If the idea (notifer + disabling event handling) is not
> good enough, we'll have to document the issue to the user, as I described above.
¯\_(ツ)_/¯ If you do not want to implement hibernation properly in vmbus
code that is totally up to you (have you read in pm.h how freeze() is
different from suspend()?).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] x86/hyperv: make vapic support x2apic mode
From: kbuild test robot @ 2019-09-30 23:04 UTC (permalink / raw)
To: Roman Kagan
Cc: kbuild-all, Michael Kelley, Lan Tianyu, Joerg Roedel,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <20190930173332.13655-1-rkagan@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[cannot apply to v5.4-rc1 next-20190930]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Roman-Kagan/x86-hyperv-make-vapic-support-x2apic-mode/20191001-044238
config: x86_64-randconfig-s0-201939 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/x86//hyperv/hv_apic.c: In function 'hv_x2apic_read':
>> arch/x86//hyperv/hv_apic.c:91:10: error: implicit declaration of function 'native_apic_msr_read' [-Werror=implicit-function-declaration]
return native_apic_msr_read(reg);
^
arch/x86//hyperv/hv_apic.c: In function 'hv_x2apic_write':
>> arch/x86//hyperv/hv_apic.c:119:3: error: implicit declaration of function 'native_apic_msr_write' [-Werror=implicit-function-declaration]
native_apic_msr_write(reg, val);
^
cc1: some warnings being treated as errors
vim +/native_apic_msr_read +91 arch/x86//hyperv/hv_apic.c
77
78 static u32 hv_x2apic_read(u32 reg)
79 {
80 u32 reg_val, hi;
81
82 switch (reg) {
83 case APIC_EOI:
84 rdmsr(HV_X64_MSR_EOI, reg_val, hi);
85 return reg_val;
86 case APIC_TASKPRI:
87 rdmsr(HV_X64_MSR_TPR, reg_val, hi);
88 return reg_val;
89
90 default:
> 91 return native_apic_msr_read(reg);
92 }
93 }
94
95 static void hv_apic_write(u32 reg, u32 val)
96 {
97 switch (reg) {
98 case APIC_EOI:
99 wrmsr(HV_X64_MSR_EOI, val, 0);
100 break;
101 case APIC_TASKPRI:
102 wrmsr(HV_X64_MSR_TPR, val, 0);
103 break;
104 default:
105 native_apic_mem_write(reg, val);
106 }
107 }
108
109 static void hv_x2apic_write(u32 reg, u32 val)
110 {
111 switch (reg) {
112 case APIC_EOI:
113 wrmsr(HV_X64_MSR_EOI, val, 0);
114 break;
115 case APIC_TASKPRI:
116 wrmsr(HV_X64_MSR_TPR, val, 0);
117 break;
118 default:
> 119 native_apic_msr_write(reg, val);
120 }
121 }
122
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30710 bytes --]
^ permalink raw reply
* Re: [PATCH] x86/hyperv: make vapic support x2apic mode
From: kbuild test robot @ 2019-09-30 22:44 UTC (permalink / raw)
To: Roman Kagan
Cc: kbuild-all, Michael Kelley, Lan Tianyu, Joerg Roedel,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <20190930173332.13655-1-rkagan@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[cannot apply to v5.4-rc1 next-20190930]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Roman-Kagan/x86-hyperv-make-vapic-support-x2apic-mode/20191001-044238
config: x86_64-randconfig-e004-201939 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/x86/hyperv/hv_apic.c: In function 'hv_x2apic_read':
>> arch/x86/hyperv/hv_apic.c:91:10: error: implicit declaration of function 'native_apic_msr_read'; did you mean 'native_apic_icr_read'? [-Werror=implicit-function-declaration]
return native_apic_msr_read(reg);
^~~~~~~~~~~~~~~~~~~~
native_apic_icr_read
arch/x86/hyperv/hv_apic.c: In function 'hv_x2apic_write':
>> arch/x86/hyperv/hv_apic.c:119:3: error: implicit declaration of function 'native_apic_msr_write'; did you mean 'native_apic_icr_write'? [-Werror=implicit-function-declaration]
native_apic_msr_write(reg, val);
^~~~~~~~~~~~~~~~~~~~~
native_apic_icr_write
cc1: some warnings being treated as errors
vim +91 arch/x86/hyperv/hv_apic.c
77
78 static u32 hv_x2apic_read(u32 reg)
79 {
80 u32 reg_val, hi;
81
82 switch (reg) {
83 case APIC_EOI:
84 rdmsr(HV_X64_MSR_EOI, reg_val, hi);
85 return reg_val;
86 case APIC_TASKPRI:
87 rdmsr(HV_X64_MSR_TPR, reg_val, hi);
88 return reg_val;
89
90 default:
> 91 return native_apic_msr_read(reg);
92 }
93 }
94
95 static void hv_apic_write(u32 reg, u32 val)
96 {
97 switch (reg) {
98 case APIC_EOI:
99 wrmsr(HV_X64_MSR_EOI, val, 0);
100 break;
101 case APIC_TASKPRI:
102 wrmsr(HV_X64_MSR_TPR, val, 0);
103 break;
104 default:
105 native_apic_mem_write(reg, val);
106 }
107 }
108
109 static void hv_x2apic_write(u32 reg, u32 val)
110 {
111 switch (reg) {
112 case APIC_EOI:
113 wrmsr(HV_X64_MSR_EOI, val, 0);
114 break;
115 case APIC_TASKPRI:
116 wrmsr(HV_X64_MSR_TPR, val, 0);
117 break;
118 default:
> 119 native_apic_msr_write(reg, val);
120 }
121 }
122
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31452 bytes --]
^ permalink raw reply
* RE: [PATCH] Input: hyperv-keyboard: Add the support of hibernation
From: Dexuan Cui @ 2019-09-30 22:09 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <20190928003156.GU237523@dtor-ws>
> From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com>
> Sent: Friday, September 27, 2019 5:32 PM
> > ...
> > pm_wakeup_pending() is tested in a lot of places in the suspend
> > process and eventually an unintentional keystroke (or mouse movement,
> > when it comes to the Hyper-V mouse driver drivers/hid/hid-hyperv.c)
> > causes the whole hibernation process to be aborted. Usually this
> > behavior is not expected by the user, I think.
>
> Why not? If a device is configured as wakeup source, then it activity
> should wake up the system, unless you disable it.
Generally speaking, I agree, but compared to a physical machine, IMO
the scenario is a little differnet when it comes to a VM running on Hyper-V:
on the host there is a window that represents the VM, and the user can
unintentionally switch the keyboard input focus to the window (or move
the mouse/cursor over the window) and then the host automatically
sends some special keystrokes (and mouse events) , and this aborts the
hibernation process.
And, when it comes to the Hyper-V mouse device, IMO it's easy for the
user to unintentionally move the mouse after the "hibernation" button
is clicked. I suppose a physical machine would have the same issue, though.
> > So, I use the notifier to set the flag variable and with it the driver can
> > know when it should not call pm_wakeup_hard_event().
>
> No, please implement hibernation support properly, as notifier + flag is
> a hack.
The keyboard/mouse driver can avoid the flag by disabling the
keyboard/mouse event handling, but the problem is that they don't know
when exactly they should disable the event handling. I think the PM
notifier is the only way to tell the drivers a hibernation process is ongoing.
Do you think this idea (notifer + disabling event handling) is acceptable?
If not, then I'll have to remove the notifer completely, and document this as
a known issue to the user: when a hibernation process is started, be careful
to not switch input focus and not touch the keyboard/mouse until the
hibernation process is finished. :-)
> In this particular case you do not want to have your
> hv_kbd_resume() to be called in place of pm_ops->thaw() as that is what
> reenables the keyboard vmbus channel and causes the undesired wakeup
> events.
This is only part of the issues. Another example: before the
pm_ops()->freeze()'s of all the devices are called, pm_wakeup_pending()
is already tested in a lot of places (e.g. in try_to_freeze_tasks ()) in the
suspend process, and can abort the whole suspend process upon the user's
unintentional input focus switch, keystroke and mouse movement.
> Your vmbus implementation should allow individual drivers to
> control the set of PM operations that they wish to use, instead of
> forcing everything through suspend/resume.
>
> Dmitry
Since the devices are pure software-emulated devices, no PM operation was
supported in the past, and now suspend/resume are the only two PM operations
we're going to support. If the idea (notifer + disabling event handling) is not
good enough, we'll have to document the issue to the user, as I described above.
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH RESEND v3 00/26] Add definition for the number of standard PCI BARs
From: Bjorn Helgaas @ 2019-09-30 19:58 UTC (permalink / raw)
To: Denis Efremov
Cc: linux-kernel, linux-pci, linux-hyperv, x86, linux-s390,
linux-alpha, linux-ia64, linux-arm-kernel, netdev, linux-fbdev,
kvm, linux-scsi, linux-ide, linux-usb, devel, linux-serial,
linux-mmc
In-Reply-To: <20190927234026.23342-1-efremov@linux.com>
On Sat, Sep 28, 2019 at 02:40:26AM +0300, Denis Efremov wrote:
> Code that iterates over all standard PCI BARs typically uses
> PCI_STD_RESOURCE_END, but this is error-prone because it requires
> "i <= PCI_STD_RESOURCE_END" rather than something like
> "i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
> way PCI_SRIOV_NUM_BARS is used. The patchset also replaces constant (6)
> with new define PCI_STD_NUM_BARS where appropriate and removes local
> declarations for the number of PCI BARs.
>
> Changes in v3:
> - Updated commits description.
> - Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops.
> - Refactored "<= BAR_5" with "< PCI_STD_NUM_BARS" in loops.
> - Removed local define GASKET_NUM_BARS.
> - Removed local define PCI_NUM_BAR_RESOURCES.
>
> Changes in v2:
> - Reversed checks in pci_iomap_range,pci_iomap_wc_range.
> - Refactored loops in vfio_pci to keep PCI_STD_RESOURCES.
> - Added 2 new patches to replace the magic constant with new define.
> - Splitted net patch in v1 to separate stmmac and dwc-xlgmac patches.
>
> Denis Efremov (26):
> PCI: Add define for the number of standard PCI BARs
> PCI: hv: Use PCI_STD_NUM_BARS
> PCI: dwc: Use PCI_STD_NUM_BARS
> PCI: endpoint: Use PCI_STD_NUM_BARS
> misc: pci_endpoint_test: Use PCI_STD_NUM_BARS
> s390/pci: Use PCI_STD_NUM_BARS
> x86/PCI: Loop using PCI_STD_NUM_BARS
> alpha/PCI: Use PCI_STD_NUM_BARS
> ia64: Use PCI_STD_NUM_BARS
> stmmac: pci: Loop using PCI_STD_NUM_BARS
> net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
> ixgb: use PCI_STD_NUM_BARS
> e1000: Use PCI_STD_NUM_BARS
> rapidio/tsi721: Loop using PCI_STD_NUM_BARS
> efifb: Loop using PCI_STD_NUM_BARS
> fbmem: use PCI_STD_NUM_BARS
> vfio_pci: Loop using PCI_STD_NUM_BARS
> scsi: pm80xx: Use PCI_STD_NUM_BARS
> ata: sata_nv: Use PCI_STD_NUM_BARS
> staging: gasket: Use PCI_STD_NUM_BARS
> serial: 8250_pci: Use PCI_STD_NUM_BARS
> pata_atp867x: Use PCI_STD_NUM_BARS
> memstick: use PCI_STD_NUM_BARS
> USB: core: Use PCI_STD_NUM_BARS
> usb: pci-quirks: Use PCI_STD_NUM_BARS
> devres: use PCI_STD_NUM_BARS
>
> arch/alpha/kernel/pci-sysfs.c | 8 ++---
> arch/ia64/sn/pci/pcibr/pcibr_dma.c | 4 +--
> arch/s390/include/asm/pci.h | 5 +--
> arch/s390/include/asm/pci_clp.h | 6 ++--
> arch/s390/pci/pci.c | 16 +++++-----
> arch/s390/pci/pci_clp.c | 6 ++--
> arch/x86/pci/common.c | 2 +-
> arch/x86/pci/intel_mid_pci.c | 2 +-
> drivers/ata/pata_atp867x.c | 2 +-
> drivers/ata/sata_nv.c | 2 +-
> drivers/memstick/host/jmb38x_ms.c | 2 +-
> drivers/misc/pci_endpoint_test.c | 8 ++---
> drivers/net/ethernet/intel/e1000/e1000.h | 1 -
> drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
> drivers/net/ethernet/intel/ixgb/ixgb.h | 1 -
> drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
> .../net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +--
> .../net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
> drivers/pci/controller/dwc/pci-dra7xx.c | 2 +-
> .../pci/controller/dwc/pci-layerscape-ep.c | 2 +-
> drivers/pci/controller/dwc/pcie-artpec6.c | 2 +-
> .../pci/controller/dwc/pcie-designware-plat.c | 2 +-
> drivers/pci/controller/dwc/pcie-designware.h | 2 +-
> drivers/pci/controller/pci-hyperv.c | 10 +++---
> drivers/pci/endpoint/functions/pci-epf-test.c | 10 +++---
> drivers/pci/pci-sysfs.c | 4 +--
> drivers/pci/pci.c | 13 ++++----
> drivers/pci/proc.c | 4 +--
> drivers/pci/quirks.c | 4 +--
> drivers/rapidio/devices/tsi721.c | 2 +-
> drivers/scsi/pm8001/pm8001_hwi.c | 2 +-
> drivers/scsi/pm8001/pm8001_init.c | 2 +-
> drivers/staging/gasket/gasket_constants.h | 3 --
> drivers/staging/gasket/gasket_core.c | 12 +++----
> drivers/staging/gasket/gasket_core.h | 4 +--
> drivers/tty/serial/8250/8250_pci.c | 8 ++---
> drivers/usb/core/hcd-pci.c | 2 +-
> drivers/usb/host/pci-quirks.c | 2 +-
> drivers/vfio/pci/vfio_pci.c | 11 ++++---
> drivers/vfio/pci/vfio_pci_config.c | 32 ++++++++++---------
> drivers/vfio/pci/vfio_pci_private.h | 4 +--
> drivers/video/fbdev/core/fbmem.c | 4 +--
> drivers/video/fbdev/efifb.c | 2 +-
> include/linux/pci-epc.h | 2 +-
> include/linux/pci.h | 2 +-
> include/uapi/linux/pci_regs.h | 1 +
> lib/devres.c | 2 +-
> 47 files changed, 112 insertions(+), 115 deletions(-)
Applied to pci/resource for v5.5, thanks!
I ended up squashing these all together because they're all related
and tiny.
^ permalink raw reply
* RE: [PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for hibernation
From: Dexuan Cui @ 2019-09-30 18:49 UTC (permalink / raw)
To: vkuznets
Cc: linux-arch@vger.kernel.org, arnd@arndb.de, bp@alien8.de,
daniel.lezcano@linaro.org, Haiyang Zhang, hpa@zytor.com,
KY Srinivasan, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@redhat.com, sashal@kernel.org,
Stephen Hemminger, tglx@linutronix.de, x86@kernel.org,
Michael Kelley, Sasha Levin
In-Reply-To: <877e5u6re3.fsf@vitty.brq.redhat.com>
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> Sent: Friday, September 27, 2019 2:05 AM
> To: Dexuan Cui <decui@microsoft.com>
>
> Dexuan Cui <decui@microsoft.com> writes:
> ...
> > So, I'm pretty sure no IPI can happen between hv_suspend() and
> hv_resume().
> > self-IPI is not supposed to happen either, since interrupts are disabled.
> >
> > IMO TLB flush should not be an issue either, unless the kernel changes page
> > tables between hv_suspend() and hv_resume(), which is not the case as I
> > checked the related code, but it looks in theory that might happen, say, in
> > the future, so if you insist we should save the variable "hv_hypercall_pg"
> > to a temporary variable and set the "hv_hypercall_pg" to NULL before we
> > disable the hypercall page
>
> Let's do it as a future proof so we can keep relying on !hv_hypercall_pg
> everywhere we need. No need to change this patch IMO, a follow-up would
> do.
> Vitaly
Now I think it would be better to do it in this patch. :-)
I'll post a v6 to follow your suggestion.
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH net v3] vsock: Fix a lockdep warning in __vsock_release()
From: Dexuan Cui @ 2019-09-30 18:43 UTC (permalink / raw)
To: davem@davemloft.net, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org, stefanha@redhat.com,
gregkh@linuxfoundation.org, arnd@arndb.de, deepa.kernel@gmail.com,
Dexuan Cui, ytht.net@gmail.com, tglx@linutronix.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, Michael Kelley,
sgarzare@redhat.com, jhansen@vmware.com
Lockdep is unhappy if two locks from the same class are held.
Fix the below warning for hyperv and virtio sockets (vmci socket code
doesn't have the issue) by using lock_sock_nested() when __vsock_release()
is called recursively:
============================================
WARNING: possible recursive locking detected
5.3.0+ #1 Not tainted
--------------------------------------------
server/1795 is trying to acquire lock:
ffff8880c5158990 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
but task is already holding lock:
ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by server/1795:
#0: ffff8880c5d05ff8 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0
#1: ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
stack backtrace:
CPU: 5 PID: 1795 Comm: server Not tainted 5.3.0+ #1
Call Trace:
dump_stack+0x67/0x90
__lock_acquire.cold.67+0xd2/0x20b
lock_acquire+0xb5/0x1c0
lock_sock_nested+0x6d/0x90
hvs_release+0x10/0x120 [hv_sock]
__vsock_release+0x24/0xf0 [vsock]
__vsock_release+0xa0/0xf0 [vsock]
vsock_release+0x12/0x30 [vsock]
__sock_release+0x37/0xa0
sock_close+0x14/0x20
__fput+0xc1/0x250
task_work_run+0x98/0xc0
do_exit+0x344/0xc60
do_group_exit+0x47/0xb0
get_signal+0x15c/0xc50
do_signal+0x30/0x720
exit_to_usermode_loop+0x50/0xa0
do_syscall_64+0x24e/0x270
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f4184e85f31
Tested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
Changes in v2:
Avoid the duplication of code in v1.
Also fix virtio socket code.
Changes in v3:
Use "lock_sock_nested(sk, level);" -- suggested by Stefano.
Add Stefano's Tested-by.
net/vmw_vsock/af_vsock.c | 16 ++++++++++++----
net/vmw_vsock/hyperv_transport.c | 2 +-
net/vmw_vsock/virtio_transport_common.c | 2 +-
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index ab47bf3ab66e..2ab43b2bba31 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -638,7 +638,7 @@ struct sock *__vsock_create(struct net *net,
}
EXPORT_SYMBOL_GPL(__vsock_create);
-static void __vsock_release(struct sock *sk)
+static void __vsock_release(struct sock *sk, int level)
{
if (sk) {
struct sk_buff *skb;
@@ -648,9 +648,17 @@ static void __vsock_release(struct sock *sk)
vsk = vsock_sk(sk);
pending = NULL; /* Compiler warning. */
+ /* The release call is supposed to use lock_sock_nested()
+ * rather than lock_sock(), if a sock lock should be acquired.
+ */
transport->release(vsk);
- lock_sock(sk);
+ /* When "level" is SINGLE_DEPTH_NESTING, use the nested
+ * version to avoid the warning "possible recursive locking
+ * detected". When "level" is 0, lock_sock_nested(sk, level)
+ * is the same as lock_sock(sk).
+ */
+ lock_sock_nested(sk, level);
sock_orphan(sk);
sk->sk_shutdown = SHUTDOWN_MASK;
@@ -659,7 +667,7 @@ static void __vsock_release(struct sock *sk)
/* Clean up any sockets that never were accepted. */
while ((pending = vsock_dequeue_accept(sk)) != NULL) {
- __vsock_release(pending);
+ __vsock_release(pending, SINGLE_DEPTH_NESTING);
sock_put(pending);
}
@@ -708,7 +716,7 @@ EXPORT_SYMBOL_GPL(vsock_stream_has_space);
static int vsock_release(struct socket *sock)
{
- __vsock_release(sock->sk);
+ __vsock_release(sock->sk, 0);
sock->sk = NULL;
sock->state = SS_FREE;
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 261521d286d6..c443db7af8d4 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
struct sock *sk = sk_vsock(vsk);
bool remove_sock;
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
remove_sock = hvs_close_lock_held(vsk);
release_sock(sk);
if (remove_sock)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 5bb70c692b1e..a666ef8fc54e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -820,7 +820,7 @@ void virtio_transport_release(struct vsock_sock *vsk)
struct sock *sk = &vsk->sk;
bool remove_sock = true;
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
if (sk->sk_type == SOCK_STREAM)
remove_sock = virtio_transport_close(vsk);
--
2.19.1
^ permalink raw reply related
* RE: [PATCH net v2] vsock: Fix a lockdep warning in __vsock_release()
From: Dexuan Cui @ 2019-09-30 18:33 UTC (permalink / raw)
To: Stefano Garzarella
Cc: davem@davemloft.net, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org, stefanha@redhat.com,
gregkh@linuxfoundation.org, arnd@arndb.de, deepa.kernel@gmail.com,
ytht.net@gmail.com, tglx@linutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Michael Kelley, jhansen@vmware.com
In-Reply-To: <20190930135125.prztj336splp74wq@steredhat>
> From: Stefano Garzarella <sgarzare@redhat.com>
> Sent: Monday, September 30, 2019 6:51 AM
> ...
> Feel free to add:
>
> Tested-by: Stefano Garzarella <sgarzare@redhat.com>
Thanks, Stefano!
I'll post a v3 with your suggestion "lock_sock_nested(sk, level);".
It does look better than v2 to me. :-)
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH] x86/hyperv: make vapic support x2apic mode
From: Roman Kagan @ 2019-09-30 17:33 UTC (permalink / raw)
To: Michael Kelley, Lan Tianyu, Joerg Roedel, K. Y. Srinivasan,
Haiyang Zhang, Stephen Hemminger, Sasha Levin, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86@kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org
Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode
when supported by the vcpus.
However, the apic access functions for Hyper-V enlightened apic assume
xapic mode only.
As a result, Linux fails to bring up secondary cpus when run as a guest
in QEMU/KVM with both hv_apic and x2apic enabled.
I didn't manage to make my instance of Hyper-V expose x2apic to the
guest; nor does Hyper-V spec document the expected behavior. However,
a Windows guest running in QEMU/KVM with hv_apic and x2apic and a big
number of vcpus (so that it turns on x2apic mode) does use enlightened
apic MSRs passing unshifted 32bit destination id and falls back to the
regular x2apic MSRs for less frequently used apic fields.
So implement the same behavior, by replacing enlightened apic access
functions (only those where it makes a difference) with their
x2apic-aware versions when x2apic is in use.
Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
Cc: stable@vger.kernel.org
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
---
arch/x86/hyperv/hv_apic.c | 48 ++++++++++++++++++++++++++++++++++++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 5c056b8aebef..9564fec00375 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -53,6 +53,11 @@ static void hv_apic_icr_write(u32 low, u32 id)
wrmsrl(HV_X64_MSR_ICR, reg_val);
}
+static void hv_x2apic_icr_write(u32 low, u32 id)
+{
+ wrmsr(HV_X64_MSR_ICR, low, id);
+}
+
static u32 hv_apic_read(u32 reg)
{
u32 reg_val, hi;
@@ -70,6 +75,23 @@ static u32 hv_apic_read(u32 reg)
}
}
+static u32 hv_x2apic_read(u32 reg)
+{
+ u32 reg_val, hi;
+
+ switch (reg) {
+ case APIC_EOI:
+ rdmsr(HV_X64_MSR_EOI, reg_val, hi);
+ return reg_val;
+ case APIC_TASKPRI:
+ rdmsr(HV_X64_MSR_TPR, reg_val, hi);
+ return reg_val;
+
+ default:
+ return native_apic_msr_read(reg);
+ }
+}
+
static void hv_apic_write(u32 reg, u32 val)
{
switch (reg) {
@@ -84,6 +106,20 @@ static void hv_apic_write(u32 reg, u32 val)
}
}
+static void hv_x2apic_write(u32 reg, u32 val)
+{
+ switch (reg) {
+ case APIC_EOI:
+ wrmsr(HV_X64_MSR_EOI, val, 0);
+ break;
+ case APIC_TASKPRI:
+ wrmsr(HV_X64_MSR_TPR, val, 0);
+ break;
+ default:
+ native_apic_msr_write(reg, val);
+ }
+}
+
static void hv_apic_eoi_write(u32 reg, u32 val)
{
struct hv_vp_assist_page *hvp = hv_vp_assist_page[smp_processor_id()];
@@ -262,9 +298,15 @@ void __init hv_apic_init(void)
if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
pr_info("Hyper-V: Using MSR based APIC access\n");
apic_set_eoi_write(hv_apic_eoi_write);
- apic->read = hv_apic_read;
- apic->write = hv_apic_write;
- apic->icr_write = hv_apic_icr_write;
+ if (x2apic_enabled()) {
+ apic->read = hv_x2apic_read;
+ apic->write = hv_x2apic_write;
+ apic->icr_write = hv_x2apic_icr_write;
+ } else {
+ apic->read = hv_apic_read;
+ apic->write = hv_apic_write;
+ apic->icr_write = hv_apic_icr_write;
+ }
apic->icr_read = hv_apic_icr_read;
}
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net v2] vsock: Fix a lockdep warning in __vsock_release()
From: Stefano Garzarella @ 2019-09-30 13:51 UTC (permalink / raw)
To: Dexuan Cui
Cc: davem@davemloft.net, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org, stefanha@redhat.com,
gregkh@linuxfoundation.org, arnd@arndb.de, deepa.kernel@gmail.com,
ytht.net@gmail.com, tglx@linutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Michael Kelley, jhansen@vmware.com
In-Reply-To: <PU1P153MB01698C46C9348B9762D5E122BF810@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Fri, Sep 27, 2019 at 05:37:20AM +0000, Dexuan Cui wrote:
> > From: linux-hyperv-owner@vger.kernel.org
> > <linux-hyperv-owner@vger.kernel.org> On Behalf Of Stefano Garzarella
> > Sent: Thursday, September 26, 2019 12:48 AM
> >
> > Hi Dexuan,
> >
> > On Thu, Sep 26, 2019 at 01:11:27AM +0000, Dexuan Cui wrote:
> > > ...
> > > NOTE: I only tested the code on Hyper-V. I can not test the code for
> > > virtio socket, as I don't have a KVM host. :-( Sorry.
> > >
> > > @Stefan, @Stefano: please review & test the patch for virtio socket,
> > > and let me know if the patch breaks anything. Thanks!
> >
> > Comment below, I'll test it ASAP!
>
> Stefano, Thank you!
>
> BTW, this is how I tested the patch:
> 1. write a socket server program in the guest. The program calls listen()
> and then calls sleep(10000 seconds). Note: accept() is not called.
>
> 2. create some connections to the server program in the guest.
>
> 3. kill the server program by Ctrl+C, and "dmesg" will show the scary
> call-trace, if the kernel is built with
> CONFIG_LOCKDEP=y
> CONFIG_LOCKDEP_SUPPORT=y
>
> 4. Apply the patch, do the same test and we should no longer see the call-trace.
>
Hi Dexuan,
I tested on virtio socket and it works as expected!
With your patch applied I don't have issues and call-trace. Without
the patch I have a very similar call-trace (as expected):
============================================
WARNING: possible recursive locking detected
5.3.0-vsock #17 Not tainted
--------------------------------------------
python3/872 is trying to acquire lock:
ffff88802b650110 (sk_lock-AF_VSOCK){+.+.}, at: virtio_transport_release+0x34/0x330 [vmw_vsock_virtio_transport_common]
but task is already holding lock:
ffff88803597ce10 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x3f/0x130 [vsock]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by python3/872:
#0: ffff88802c957180 (&sb->s_type->i_mutex_key#8){+.+.}, at: __sock_release+0x2d/0xb0
#1: ffff88803597ce10 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x3f/0x130 [vsock]
stack backtrace:
CPU: 0 PID: 872 Comm: python3 Not tainted 5.3.0-vsock #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
Call Trace:
dump_stack+0x85/0xc0
__lock_acquire.cold+0xad/0x22b
lock_acquire+0xc4/0x1a0
? virtio_transport_release+0x34/0x330 [vmw_vsock_virtio_transport_common]
lock_sock_nested+0x5d/0x80
? virtio_transport_release+0x34/0x330 [vmw_vsock_virtio_transport_common]
virtio_transport_release+0x34/0x330 [vmw_vsock_virtio_transport_common]
? mark_held_locks+0x49/0x70
? _raw_spin_unlock_irqrestore+0x44/0x60
__vsock_release+0x2d/0x130 [vsock]
__vsock_release+0xb9/0x130 [vsock]
vsock_release+0x12/0x30 [vsock]
__sock_release+0x3d/0xb0
sock_close+0x14/0x20
__fput+0xc1/0x250
task_work_run+0x93/0xb0
exit_to_usermode_loop+0xd3/0xe0
syscall_return_slowpath+0x205/0x310
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Feel free to add:
Tested-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* RE: [PATCH] HID: hyperv: Add the support of hibernation
From: Dexuan Cui @ 2019-09-29 17:44 UTC (permalink / raw)
To: Sasha Levin
Cc: Jiri Kosina, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
benjamin.tissoires@redhat.com, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <20190927120513.GM8171@sasha-vm>
> From: Sasha Levin <sashal@kernel.org>
> Sent: Friday, September 27, 2019 5:05 AM
> To: Dexuan Cui <decui@microsoft.com>
> Cc: Jiri Kosina <jikos@kernel.org>; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; benjamin.tissoires@redhat.com;
> linux-hyperv@vger.kernel.org; linux-input@vger.kernel.org;
> linux-kernel@vger.kernel.org; Michael Kelley <mikelley@microsoft.com>
> Subject: Re: [PATCH] HID: hyperv: Add the support of hibernation
>
> On Fri, Sep 27, 2019 at 05:42:31AM +0000, Dexuan Cui wrote:
> >> From: Jiri Kosina <jikos@kernel.org>
> >> Sent: Thursday, September 26, 2019 6:23 AM
> >> To: Dexuan Cui <decui@microsoft.com>
> >>
> >> On Thu, 26 Sep 2019, Jiri Kosina wrote:
> >>
> >> > > > This patch is basically a pure Hyper-V specific change and it has a
> >> > > > build dependency on the commit 271b2224d42f ("Drivers: hv: vmbus:
> >> > > > Implement
> >> > > > suspend/resume for VSC drivers for hibernation"), which is on Sasha
> >> Levin's
> >> > > > Hyper-V tree's hyperv-next branch [ ... snipped ...]
> >> > > >
> >> > > > I request this patch should go through Sasha's tree rather than the
> >> > > > input subsystem's tree.
> >> > > >
> >> > > > Hi Jiri, Benjamin, can you please Ack?
> >> > >
> >> > > Hi Jiri, Benjamin,
> >> > > Can you please take a look at the patch?
> >> >
> >> > Hi Dexuan,
> >> >
> >> > I am planning to process it once 5.4 merge window is over and thus hid.git
> >> > is open again for 5.5 material.
> >>
> >> Ah, now I see you asked for this go through hyperv tree. For that, feel
> >> free to add
> >> Acked-by: Jiri Kosina <jkosina@suse.cz>
> >> Jiri Kosina
> >
> >Thanks for the Ack, Jiri!
> >
> >I have a bunch of patches, including this one, to support Linux VM's
> hibernation
> >when the VM runs on Hyper-V. I just feel it would be better for all of them to
> >go through the Hyper-V tree. :-)
>
> Thank Dexuan, Jiri,
>
> Dexuan, I've been silently ignoring your patches for the past few weeks
> for the same reason as Jiri has mentioned. I'll pick them all up once
> the 5.4 merge window closes in a few days.
>
> Thanks,
> Sasha
Thanks, Sasha!
BTW, I'll post a v2 for this patch, as IMO I may be able to get rid of the
mousevsc_pm_notify in this patch by disabling the channel callback
in the suspend function.
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH AUTOSEL 5.3 11/49] PCI: pci-hyperv: Fix build errors on non-SYSFS config
From: Sasha Levin @ 2019-09-29 17:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Lorenzo Pieralisi, Haiyang Zhang, Matthew Wilcox,
Jake Oshins, K. Y. Srinivasan, Stephen Hemminger,
Stephen Hemminger, Sasha Levin, Bjorn Helgaas, linux-pci,
linux-hyperv, Dexuan Cui
In-Reply-To: <20190929173053.8400-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f58ba5e3f6863ea4486952698898848a6db726c2 ]
Fix build errors when building almost-allmodconfig but with SYSFS
not set (not enabled). Fixes these build errors:
ERROR: "pci_destroy_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
ERROR: "pci_create_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
drivers/pci/slot.o is only built when SYSFS is enabled, so
pci-hyperv.o has an implicit dependency on SYSFS.
Make that explicit.
Also, depending on X86 && X86_64 is not needed, so just change that
to depend on X86_64.
Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jake Oshins <jakeo@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-hyperv@vger.kernel.org
Cc: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 2ab92409210af..297bf928d6522 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -181,7 +181,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
+ depends on X86_64 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && SYSFS
help
The PCI device frontend driver allows the kernel to import arbitrary
PCI devices from a PCI backend to support PCI driver domains.
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 10/42] PCI: pci-hyperv: Fix build errors on non-SYSFS config
From: Sasha Levin @ 2019-09-29 17:32 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Lorenzo Pieralisi, Haiyang Zhang, Matthew Wilcox,
Jake Oshins, K. Y. Srinivasan, Stephen Hemminger,
Stephen Hemminger, Sasha Levin, Bjorn Helgaas, linux-pci,
linux-hyperv, Dexuan Cui
In-Reply-To: <20190929173244.8918-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f58ba5e3f6863ea4486952698898848a6db726c2 ]
Fix build errors when building almost-allmodconfig but with SYSFS
not set (not enabled). Fixes these build errors:
ERROR: "pci_destroy_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
ERROR: "pci_create_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
drivers/pci/slot.o is only built when SYSFS is enabled, so
pci-hyperv.o has an implicit dependency on SYSFS.
Make that explicit.
Also, depending on X86 && X86_64 is not needed, so just change that
to depend on X86_64.
Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jake Oshins <jakeo@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-hyperv@vger.kernel.org
Cc: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 2ab92409210af..297bf928d6522 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -181,7 +181,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
+ depends on X86_64 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && SYSFS
help
The PCI device frontend driver allows the kernel to import arbitrary
PCI devices from a PCI backend to support PCI driver domains.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Input: hyperv-keyboard: Add the support of hibernation
From: dmitry.torokhov @ 2019-09-28 0:31 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <PU1P153MB016914A7C827CA35D7FEB66ABF8B0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Sat, Sep 21, 2019 at 06:56:04AM +0000, Dexuan Cui wrote:
> > From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com>
> > Sent: Thursday, September 19, 2019 9:18 AM
> >
> > Hi Dexuan,
> >
> > On Wed, Sep 11, 2019 at 11:36:20PM +0000, Dexuan Cui wrote:
> > > We need hv_kbd_pm_notify() to make sure the pm_wakeup_hard_event()
> > call
> > > does not prevent the system from entering hibernation: the hibernation
> > > is a relatively long process, which can be aborted by the call
> > > pm_wakeup_hard_event(), which is invoked upon keyboard events.
> > >
> > > diff --git a/drivers/input/serio/hyperv-keyboard.c
> > b/drivers/input/serio/hyperv-keyboard.c
> > > index 88ae7c2..277dc4c 100644
> > > --- a/drivers/input/serio/hyperv-keyboard.c
> > > +++ b/drivers/input/serio/hyperv-keyboard.c
> > > @@ -10,6 +10,7 @@
> > > #include <linux/hyperv.h>
> > > #include <linux/serio.h>
> > > #include <linux/slab.h>
> > > +#include <linux/suspend.h>
> > >
> > > /*
> > > * Current version 1.0
> > > @@ -95,6 +96,9 @@ struct hv_kbd_dev {
> > > struct completion wait_event;
> > > spinlock_t lock; /* protects 'started' field */
> > > bool started;
> > > +
> > > + struct notifier_block pm_nb;
> > > + bool hibernation_in_progress;
> >
> > Why do you use notifier block instead of exposing proper PM methods if
> > you want to support hibernation?
> >
> > Dmitry
>
> Hi,
> In the patch I do implement hv_kbd_suspend() and hv_kbd_resume(), and
> add them into the hv_kbd_drv struct:
>
> @@ -416,6 +472,8 @@ static struct hv_driver hv_kbd_drv = {
> .id_table = id_table,
> .probe = hv_kbd_probe,
> .remove = hv_kbd_remove,
> + .suspend = hv_kbd_suspend,
> + .resume = hv_kbd_resume,
>
> The .suspend and .resume callbacks are inroduced by another patch (which
> uses the dev_pm_ops struct):
> 271b2224d42f ("Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation")
> (which is on the Hyper-V tree's hyperv-next branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/commit/?h=hyperv-next&id=271b2224d42f88870e6b060924ee374871c131fc )
>
> The only purpose of the notifier is to set the variable
> kbd_dev->hibernation_in_progress to true during the hibernation process.
>
> As I explained in the changelog, the hibernation is a long process (which
> can take 10+ seconds), during which the user may unintentionally touch
> the keyboard, causing key up/down events, which are still handled by
> hv_kbd_on_receive(), which calls pm_wakeup_hard_event(), which
> calls some other functions which increase the global counter
> "pm_abort_suspend", and hence pm_wakeup_pending() becomes true.
>
> pm_wakeup_pending() is tested in a lot of places in the suspend
> process and eventually an unintentional keystroke (or mouse movement,
> when it comes to the Hyper-V mouse driver drivers/hid/hid-hyperv.c)
> causes the whole hibernation process to be aborted. Usually this
> behavior is not expected by the user, I think.
Why not? If a device is configured as wakeup source, then it activity
should wake up the system, unless you disable it.
>
> So, I use the notifier to set the flag variable and with it the driver can
> know when it should not call pm_wakeup_hard_event().
No, please implement hibernation support properly, as notifier + flag is
a hack. In this particular case you do not want to have your
hv_kbd_resume() to be called in place of pm_ops->thaw() as that is what
reenables the keyboard vmbus channel and causes the undesired wakeup
events. Your vmbus implementation should allow individual drivers to
control the set of PM operations that they wish to use, instead of
forcing everything through suspend/resume.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH RESEND v3 01/26] PCI: Add define for the number of standard PCI BARs
From: Denis Efremov @ 2019-09-27 23:43 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, linux-hyperv, x86,
linux-s390, linux-alpha, linux-ia64, linux-arm-kernel
In-Reply-To: <20190916204158.6889-3-efremov@linux.com>
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END. However, it requires the "unusual" loop condition
"i <= PCI_STD_RESOURCE_END" rather than something more standard like
"i < PCI_STD_NUM_BARS".
This patch adds the definition PCI_STD_NUM_BARS which is equivalent to
"PCI_STD_RESOURCE_END + 1". To iterate through all possible BARs, loop
conditions changed to the *number* of BARs "i < PCI_STD_NUM_BARS",
instead of the index of the last valid BAR "i <= PCI_STD_RESOURCE_END"
or PCI_ROM_RESOURCE. The magic constant (6) is also replaced with new
define PCI_STD_NUM_BARS.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/pci/pci-sysfs.c | 4 ++--
drivers/pci/pci.c | 13 +++++++------
drivers/pci/proc.c | 4 ++--
drivers/pci/quirks.c | 4 ++--
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
6 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 965c72104150..3e26b8e03bd5 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1257,7 +1257,7 @@ static void pci_remove_resource_files(struct pci_dev *pdev)
{
int i;
- for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct bin_attribute *res_attr;
res_attr = pdev->res_attr[i];
@@ -1328,7 +1328,7 @@ static int pci_create_resource_files(struct pci_dev *pdev)
int retval;
/* Expose the PCI resources from this device as files */
- for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
/* skip empty resources */
if (!pci_resource_len(pdev, i))
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1b27b5af3d55..7d543986026b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -674,7 +674,7 @@ struct resource *pci_find_resource(struct pci_dev *dev, struct resource *res)
{
int i;
- for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct resource *r = &dev->resource[i];
if (r->start && resource_contains(r, res))
@@ -3768,7 +3768,7 @@ void pci_release_selected_regions(struct pci_dev *pdev, int bars)
{
int i;
- for (i = 0; i < 6; i++)
+ for (i = 0; i < PCI_STD_NUM_BARS; i++)
if (bars & (1 << i))
pci_release_region(pdev, i);
}
@@ -3779,7 +3779,7 @@ static int __pci_request_selected_regions(struct pci_dev *pdev, int bars,
{
int i;
- for (i = 0; i < 6; i++)
+ for (i = 0; i < PCI_STD_NUM_BARS; i++)
if (bars & (1 << i))
if (__pci_request_region(pdev, i, res_name, excl))
goto err_out;
@@ -3827,7 +3827,7 @@ EXPORT_SYMBOL(pci_request_selected_regions_exclusive);
void pci_release_regions(struct pci_dev *pdev)
{
- pci_release_selected_regions(pdev, (1 << 6) - 1);
+ pci_release_selected_regions(pdev, (1 << PCI_STD_NUM_BARS) - 1);
}
EXPORT_SYMBOL(pci_release_regions);
@@ -3846,7 +3846,8 @@ EXPORT_SYMBOL(pci_release_regions);
*/
int pci_request_regions(struct pci_dev *pdev, const char *res_name)
{
- return pci_request_selected_regions(pdev, ((1 << 6) - 1), res_name);
+ return pci_request_selected_regions(pdev,
+ ((1 << PCI_STD_NUM_BARS) - 1), res_name);
}
EXPORT_SYMBOL(pci_request_regions);
@@ -3868,7 +3869,7 @@ EXPORT_SYMBOL(pci_request_regions);
int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
{
return pci_request_selected_regions_exclusive(pdev,
- ((1 << 6) - 1), res_name);
+ ((1 << PCI_STD_NUM_BARS) - 1), res_name);
}
EXPORT_SYMBOL(pci_request_regions_exclusive);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index fe7fe678965b..cb61ec2c24e8 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -248,13 +248,13 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma)
}
/* Make sure the caller is mapping a real resource for this device */
- for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (dev->resource[i].flags & res_bit &&
pci_mmap_fits(dev, i, vma, PCI_MMAP_PROCFS))
break;
}
- if (i >= PCI_ROM_RESOURCE)
+ if (i >= PCI_STD_NUM_BARS)
return -ENODEV;
if (fpriv->mmap_state == pci_mmap_mem &&
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 44c4ae1abd00..998454b0ae8d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -475,7 +475,7 @@ static void quirk_extend_bar_to_page(struct pci_dev *dev)
{
int i;
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct resource *r = &dev->resource[i];
if (r->flags & IORESOURCE_MEM && resource_size(r) < PAGE_SIZE) {
@@ -1810,7 +1810,7 @@ static void quirk_alder_ioapic(struct pci_dev *pdev)
* The next five BARs all seem to be rubbish, so just clean
* them out.
*/
- for (i = 1; i < 6; i++)
+ for (i = 1; i < PCI_STD_NUM_BARS; i++)
memset(&pdev->resource[i], 0, sizeof(pdev->resource[i]));
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EESSC, quirk_alder_ioapic);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 82e4cd1b7ac3..cf7d16305243 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -76,7 +76,7 @@ enum pci_mmap_state {
enum {
/* #0-5: standard PCI resources */
PCI_STD_RESOURCES,
- PCI_STD_RESOURCE_END = 5,
+ PCI_STD_RESOURCE_END = PCI_STD_RESOURCES + PCI_STD_NUM_BARS - 1,
/* #6: expansion ROM resource */
PCI_ROM_RESOURCE,
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index f28e562d7ca8..68b571d491eb 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -34,6 +34,7 @@
* of which the first 64 bytes are standardized as follows:
*/
#define PCI_STD_HEADER_SIZEOF 64
+#define PCI_STD_NUM_BARS 6 /* Number of standard BARs */
#define PCI_VENDOR_ID 0x00 /* 16 bits */
#define PCI_DEVICE_ID 0x02 /* 16 bits */
#define PCI_COMMAND 0x04 /* 16 bits */
--
2.21.0
^ permalink raw reply related
* [PATCH RESEND v3 00/26] Add definition for the number of standard PCI BARs
From: Denis Efremov @ 2019-09-27 23:40 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, linux-hyperv, x86,
linux-s390, linux-alpha, linux-ia64, linux-arm-kernel, netdev,
linux-fbdev, kvm, linux-scsi, linux-ide, linux-usb, devel,
linux-serial, linux-mmc
In-Reply-To: <20190916204158.6889-3-efremov@linux.com>
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END, but this is error-prone because it requires
"i <= PCI_STD_RESOURCE_END" rather than something like
"i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
way PCI_SRIOV_NUM_BARS is used. The patchset also replaces constant (6)
with new define PCI_STD_NUM_BARS where appropriate and removes local
declarations for the number of PCI BARs.
Changes in v3:
- Updated commits description.
- Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops.
- Refactored "<= BAR_5" with "< PCI_STD_NUM_BARS" in loops.
- Removed local define GASKET_NUM_BARS.
- Removed local define PCI_NUM_BAR_RESOURCES.
Changes in v2:
- Reversed checks in pci_iomap_range,pci_iomap_wc_range.
- Refactored loops in vfio_pci to keep PCI_STD_RESOURCES.
- Added 2 new patches to replace the magic constant with new define.
- Splitted net patch in v1 to separate stmmac and dwc-xlgmac patches.
Denis Efremov (26):
PCI: Add define for the number of standard PCI BARs
PCI: hv: Use PCI_STD_NUM_BARS
PCI: dwc: Use PCI_STD_NUM_BARS
PCI: endpoint: Use PCI_STD_NUM_BARS
misc: pci_endpoint_test: Use PCI_STD_NUM_BARS
s390/pci: Use PCI_STD_NUM_BARS
x86/PCI: Loop using PCI_STD_NUM_BARS
alpha/PCI: Use PCI_STD_NUM_BARS
ia64: Use PCI_STD_NUM_BARS
stmmac: pci: Loop using PCI_STD_NUM_BARS
net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
ixgb: use PCI_STD_NUM_BARS
e1000: Use PCI_STD_NUM_BARS
rapidio/tsi721: Loop using PCI_STD_NUM_BARS
efifb: Loop using PCI_STD_NUM_BARS
fbmem: use PCI_STD_NUM_BARS
vfio_pci: Loop using PCI_STD_NUM_BARS
scsi: pm80xx: Use PCI_STD_NUM_BARS
ata: sata_nv: Use PCI_STD_NUM_BARS
staging: gasket: Use PCI_STD_NUM_BARS
serial: 8250_pci: Use PCI_STD_NUM_BARS
pata_atp867x: Use PCI_STD_NUM_BARS
memstick: use PCI_STD_NUM_BARS
USB: core: Use PCI_STD_NUM_BARS
usb: pci-quirks: Use PCI_STD_NUM_BARS
devres: use PCI_STD_NUM_BARS
arch/alpha/kernel/pci-sysfs.c | 8 ++---
arch/ia64/sn/pci/pcibr/pcibr_dma.c | 4 +--
arch/s390/include/asm/pci.h | 5 +--
arch/s390/include/asm/pci_clp.h | 6 ++--
arch/s390/pci/pci.c | 16 +++++-----
arch/s390/pci/pci_clp.c | 6 ++--
arch/x86/pci/common.c | 2 +-
arch/x86/pci/intel_mid_pci.c | 2 +-
drivers/ata/pata_atp867x.c | 2 +-
drivers/ata/sata_nv.c | 2 +-
drivers/memstick/host/jmb38x_ms.c | 2 +-
drivers/misc/pci_endpoint_test.c | 8 ++---
drivers/net/ethernet/intel/e1000/e1000.h | 1 -
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
drivers/net/ethernet/intel/ixgb/ixgb.h | 1 -
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +--
.../net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
drivers/pci/controller/dwc/pci-dra7xx.c | 2 +-
.../pci/controller/dwc/pci-layerscape-ep.c | 2 +-
drivers/pci/controller/dwc/pcie-artpec6.c | 2 +-
.../pci/controller/dwc/pcie-designware-plat.c | 2 +-
drivers/pci/controller/dwc/pcie-designware.h | 2 +-
drivers/pci/controller/pci-hyperv.c | 10 +++---
drivers/pci/endpoint/functions/pci-epf-test.c | 10 +++---
drivers/pci/pci-sysfs.c | 4 +--
drivers/pci/pci.c | 13 ++++----
drivers/pci/proc.c | 4 +--
drivers/pci/quirks.c | 4 +--
drivers/rapidio/devices/tsi721.c | 2 +-
drivers/scsi/pm8001/pm8001_hwi.c | 2 +-
drivers/scsi/pm8001/pm8001_init.c | 2 +-
drivers/staging/gasket/gasket_constants.h | 3 --
drivers/staging/gasket/gasket_core.c | 12 +++----
drivers/staging/gasket/gasket_core.h | 4 +--
drivers/tty/serial/8250/8250_pci.c | 8 ++---
drivers/usb/core/hcd-pci.c | 2 +-
drivers/usb/host/pci-quirks.c | 2 +-
drivers/vfio/pci/vfio_pci.c | 11 ++++---
drivers/vfio/pci/vfio_pci_config.c | 32 ++++++++++---------
drivers/vfio/pci/vfio_pci_private.h | 4 +--
drivers/video/fbdev/core/fbmem.c | 4 +--
drivers/video/fbdev/efifb.c | 2 +-
include/linux/pci-epc.h | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
lib/devres.c | 2 +-
47 files changed, 112 insertions(+), 115 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH v3 02/26] PCI: hv: Use PCI_STD_NUM_BARS
From: Bjorn Helgaas @ 2019-09-27 12:43 UTC (permalink / raw)
To: Denis Efremov
Cc: linux-kernel, linux-pci, Andrew Murray, linux-hyperv,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin
In-Reply-To: <20190926220531.GA200826@google.com>
On Thu, Sep 26, 2019 at 05:05:31PM -0500, Bjorn Helgaas wrote:
> On Mon, Sep 16, 2019 at 11:41:34PM +0300, Denis Efremov wrote:
> > Replace the magic constant (6) with define PCI_STD_NUM_BARS representing
> > the number of PCI BARs.
>
> For some reason patches 0 and 1 didn't make it to the list. Can you
> resend them?
(No need to resend the whole series, which might annoy all the other
maintainers. Just send 0 (the cover letter) and 1 (which I assume
adds the PCI_STD_NUM_BARS definition)).
^ permalink raw reply
* Re: [PATCH] HID: hyperv: Add the support of hibernation
From: Sasha Levin @ 2019-09-27 12:05 UTC (permalink / raw)
To: Dexuan Cui
Cc: Jiri Kosina, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
benjamin.tissoires@redhat.com, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <PU1P153MB016973F30CC1A52E46D15230BF810@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Fri, Sep 27, 2019 at 05:42:31AM +0000, Dexuan Cui wrote:
>> From: Jiri Kosina <jikos@kernel.org>
>> Sent: Thursday, September 26, 2019 6:23 AM
>> To: Dexuan Cui <decui@microsoft.com>
>>
>> On Thu, 26 Sep 2019, Jiri Kosina wrote:
>>
>> > > > This patch is basically a pure Hyper-V specific change and it has a
>> > > > build dependency on the commit 271b2224d42f ("Drivers: hv: vmbus:
>> > > > Implement
>> > > > suspend/resume for VSC drivers for hibernation"), which is on Sasha
>> Levin's
>> > > > Hyper-V tree's hyperv-next branch [ ... snipped ...]
>> > > >
>> > > > I request this patch should go through Sasha's tree rather than the
>> > > > input subsystem's tree.
>> > > >
>> > > > Hi Jiri, Benjamin, can you please Ack?
>> > >
>> > > Hi Jiri, Benjamin,
>> > > Can you please take a look at the patch?
>> >
>> > Hi Dexuan,
>> >
>> > I am planning to process it once 5.4 merge window is over and thus hid.git
>> > is open again for 5.5 material.
>>
>> Ah, now I see you asked for this go through hyperv tree. For that, feel
>> free to add
>> Acked-by: Jiri Kosina <jkosina@suse.cz>
>> Jiri Kosina
>
>Thanks for the Ack, Jiri!
>
>I have a bunch of patches, including this one, to support Linux VM's hibernation
>when the VM runs on Hyper-V. I just feel it would be better for all of them to
>go through the Hyper-V tree. :-)
Thank Dexuan, Jiri,
Dexuan, I've been silently ignoring your patches for the past few weeks
for the same reason as Jiri has mentioned. I'll pick them all up once
the 5.4 merge window closes in a few days.
--
Thanks,
Sasha
^ permalink raw reply
* [RFC PATCH 09/13] hv_sock: set VMADDR_CID_HOST in the hvs_remote_addr_init()
From: Stefano Garzarella @ 2019-09-27 11:26 UTC (permalink / raw)
To: netdev
Cc: linux-hyperv, K. Y. Srinivasan, Stefan Hajnoczi, Sasha Levin,
linux-kernel, kvm, David S. Miller, virtualization,
Stephen Hemminger, Jason Wang, Michael S. Tsirkin, Haiyang Zhang,
Dexuan Cui, Jorgen Hansen
In-Reply-To: <20190927112703.17745-1-sgarzare@redhat.com>
Remote peer is always the host, so we set VMADDR_CID_HOST as
remote CID instead of VMADDR_CID_ANY.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
net/vmw_vsock/hyperv_transport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 4f47af2054dd..306310794522 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -186,7 +186,8 @@ static void hvs_remote_addr_init(struct sockaddr_vm *remote,
static u32 host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT;
struct sock *sk;
- vsock_addr_init(remote, VMADDR_CID_ANY, VMADDR_PORT_ANY);
+ /* Remote peer is always the host */
+ vsock_addr_init(remote, VMADDR_CID_HOST, VMADDR_PORT_ANY);
while (1) {
/* Wrap around ? */
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox