linux-stable.git/drivers/hv, branch v4.19.166

hv_balloon: disable warning when floor reached

2020-11-18T18:18:41+00:00

[ Upstream commit 2c3bd2a5c86fe744e8377733c5e511a5ca1e14f5 ]

It is not an error if the host requests to balloon down, but the VM
refuses to do so. Without this change a warning is logged in dmesg
every five minutes.

Fixes:  b3bb97b8a49f3 ("Drivers: hv: balloon: Add logging for dynamic memory operations")

Signed-off-by: Olaf Hering 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20201008071216.16554-1-olaf@aepfle.de
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload

2020-09-23T10:10:59+00:00

[ Upstream commit 911e1987efc8f3e6445955fbae7f54b428b92bd3 ]

vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message
coming from Hyper-V.  But if the message isn't found for some reason,
the panic path gets hung forever.  Add a timeout of 10 seconds to prevent
this.

Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()")
Signed-off-by: Michael Kelley 
Reviewed-by: Dexuan Cui 
Reviewed-by: Vitaly Kuznetsov 
Link: https://lore.kernel.org/r/1600026449-23651-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)

2020-08-11T13:32:33+00:00

[ Upstream commit ddc9d357b991838c2d975e8d7e4e9db26f37a7ff ]

When a Linux hv_sock app tries to connect to a Service GUID on which no
host app is listening, a recent host (RS3+) sends a
CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such
a warning:

unknown msgtype=23
WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc

Actually Linux can safely ignore the message because the Linux app's
connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT
and vsock_stream_connect(). We don't bother to make use of the message
because: 1) it's only supported on recent hosts; 2) a non-trivial effort
is required to use the message in Linux, but the benefit is small.

So, let's not see the warning by silently ignoring the message.

Signed-off-by: Dexuan Cui 
Reviewed-by: Michael Kelley 
Signed-off-by: Sasha Levin

x86/Hyper-V: Report crash data in die() when panic_on_oops is set

2020-04-23T08:30:17+00:00

[ Upstream commit f3a99e761efa616028b255b4de58e9b5b87c5545 ]

When oops happens with panic_on_oops unset, the oops
thread is killed by die() and system continues to run.
In such case, guest should not report crash register
data to host since system still runs. Check panic_on_oops
and return directly in hyperv_report_panic() when the function
is called in the die() and panic_on_oops is unset. Fix it.

Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful")
Signed-off-by: Tianyu Lan 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20200406155331.2105-7-Tianyu.Lan@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

x86/Hyper-V: Report crash register data when sysctl_record_panic_msg is not set

2020-04-23T08:30:16+00:00

[ Upstream commit 040026df7088c56ccbad28f7042308f67bde63df ]

When sysctl_record_panic_msg is not set, the panic will
not be reported to Hyper-V via hyperv_report_panic_msg().
So the crash should be reported via hyperv_report_panic().

Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic")
Reviewed-by: Michael Kelley 
Signed-off-by: Tianyu Lan 
Link: https://lore.kernel.org/r/20200406155331.2105-6-Tianyu.Lan@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

x86/Hyper-V: Trigger crash enlightenment only once during system crash.

2020-04-23T08:30:16+00:00

[ Upstream commit 73f26e526f19afb3a06b76b970a76bcac2cafd05 ]

When a guest VM panics, Hyper-V should be notified only once via the
crash synthetic MSRs.  Current Linux code might write these crash MSRs
twice during a system panic:
1) hyperv_panic/die_event() calling hyperv_report_panic()
2) hv_kmsg_dump() calling hyperv_report_panic_msg()

Fix this by not calling hyperv_report_panic() if a kmsg dump has been
successfully registered.  The notification will happen later via
hyperv_report_panic_msg().

Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful")
Reviewed-by: Michael Kelley 
Signed-off-by: Tianyu Lan 
Link: https://lore.kernel.org/r/20200406155331.2105-4-Tianyu.Lan@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

x86/Hyper-V: Free hv_panic_page when fail to register kmsg dump

2020-04-23T08:30:16+00:00

[ Upstream commit 7f11a2cc10a4ae3a70e2c73361f4a9a33503539b ]

If kmsg_dump_register() fails, hv_panic_page will not be used
anywhere.  So free and reset it.

Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic")
Reviewed-by: Michael Kelley 
Signed-off-by: Tianyu Lan 
Link: https://lore.kernel.org/r/20200406155331.2105-3-Tianyu.Lan@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

x86/Hyper-V: Unload vmbus channel in hv panic callback

2020-04-23T08:30:16+00:00

[ Upstream commit 74347a99e73ae00b8385f1209aaea193c670f901 ]

When kdump is not configured, a Hyper-V VM might still respond to
network traffic after a kernel panic when kernel parameter panic=0.
The panic CPU goes into an infinite loop with interrupts enabled,
and the VMbus driver interrupt handler still works because the
VMbus connection is unloaded only in the kdump path.  The network
responses make the other end of the connection think the VM is
still functional even though it has panic'ed, which could affect any
failover actions that should be taken.

Fix this by unloading the VMbus connection during the panic process.
vmbus_initiate_unload() could then be called twice (e.g., by
hyperv_panic_event() and hv_crash_handler(), so reset the connection
state in vmbus_initiate_unload() to ensure the unload is done only
once.

Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic")
Reviewed-by: Michael Kelley 
Signed-off-by: Tianyu Lan 
Link: https://lore.kernel.org/r/20200406155331.2105-2-Tianyu.Lan@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Sasha Levin

hv_balloon: Balloon up according to request page number

2020-02-11T12:34:01+00:00

commit d33c240d47dab4fd15123d9e73fc8810cbc6ed6a upstream.

Current code has assumption that balloon request memory size aligns
with 2MB. But actually Hyper-V doesn't guarantee such alignment. When
balloon driver receives non-aligned balloon request, it produces warning
and balloon up more memory than requested in order to keep 2MB alignment.
Remove the warning and balloon up memory according to actual requested
memory size.

Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block")
Cc: stable@vger.kernel.org
Reviewed-by: Vitaly Kuznetsov 
Signed-off-by: Tianyu Lan 
Reviewed-by: Michael Kelley 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

vmbus: keep pointer to ring buffer page

2019-11-20T17:47:31+00:00

[ Upstream commit 52a42c2a90226dc61c99bbd0cb096deeb52c334b ]

Avoid going from struct page to virt address (and back) by just
keeping pointer to the allocated pages instead of virt address.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin