linux-stable.git/drivers/hv, branch linux-4.1.y

Revert "x86/retpoline/hyperv: Convert assembler indirect jumps"

2018-03-21T03:49:54+00:00

This reverts commit db8171fb71e4af877f400406d8f114c4021d2ef2.

Signed-off-by: Sasha Levin

x86/retpoline/hyperv: Convert assembler indirect jumps

2018-03-21T03:49:44+00:00

[ Upstream commit e70e5892b28c18f517f29ab6e83bd57705104b31 ]

Convert all indirect jumps in hyperv inline asm code to use non-speculative
sequences when CONFIG_RETPOLINE is enabled.

Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Acked-by: Arjan van de Ven 
Acked-by: Ingo Molnar 
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel 
Cc: Andi Kleen 
Cc: Josh Poimboeuf 
Cc: thomas.lendacky@amd.com
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Jiri Kosina 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Kees Cook 
Cc: Tim Chen 
Cc: Greg Kroah-Hartman 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/1515707194-20531-9-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Sasha Levin

Drivers: hv: balloon: don't crash when memory is added in non-sorted order

2018-01-17T17:29:20+00:00

[ Upstream commit 77c0c9735bc0ba5898e637a3a20d6bcb50e3f67d ]

When we iterate through all HA regions in handle_pg_range() we have an
assumption that all these regions are sorted in the list and the
'start_pfn >= has->end_pfn' check is enough to find the proper region.
Unfortunately it's not the case with WS2016 where host can hot-add regions
in a different order. We end up modifying the wrong HA region and crashing
later on pages online. Modify the check to make sure we found the region
we were searching for while iterating. Fix the same check in pfn_covered()
as well.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Drivers: hv: balloon: account for gaps in hot add regions

2017-06-13T13:29:17+00:00

[ Upstream commit cb7a5724c7e1bfb5766ad1c3beba14cc715991cf ]

I'm observing the following hot add requests from the WS2012 host:

hot_add_req: start_pfn = 0x108200 count = 330752
hot_add_req: start_pfn = 0x158e00 count = 193536
hot_add_req: start_pfn = 0x188400 count = 239616

As the host doesn't specify hot add regions we're trying to create
128Mb-aligned region covering the first request, we create the 0x108000 -
0x160000 region and we add 0x108000 - 0x158e00 memory. The second request
passes the pfn_covered() check, we enlarge the region to 0x108000 -
0x190000 and add 0x158e00 - 0x188200 memory. The problem emerges with the
third request as it starts at 0x188400 so there is a 0x200 gap which is
not covered. As the end of our region is 0x190000 now it again passes the
pfn_covered() check were we just adjust the covered_end_pfn and make it
0x188400 instead of 0x188200 which means that we'll try to online
0x188200-0x188400 pages but these pages were never assigned to us and we
crash.

We can't react to such requests by creating new hot add regions as it may
happen that the whole suggested range falls into the previously identified
128Mb-aligned area so we'll end up adding nothing or create intersecting
regions and our current logic doesn't allow that. Instead, create a list of
such 'gaps' and check for them in the page online callback.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Drivers: hv: balloon: keep track of where ha_region starts

2017-06-13T13:29:17+00:00

[ Upstream commit 7cf3b79ec85ee1a5bbaaf936bb1d050dc652983b ]

Windows 2012 (non-R2) does not specify hot add region in hot add requests
and the logic in hot_add_req() is trying to find a 128Mb-aligned region
covering the request. It may also happen that host's requests are not 128Mb
aligned and the created ha_region will start before the first specified
PFN. We can't online these non-present pages but we don't remember the real
start of the region.

This is a regression introduced by the commit 5abbbb75d733 ("Drivers: hv:
hv_balloon: don't lose memory when onlining order is not natural"). While
the idea of keeping the 'moving window' was wrong (as there is no guarantee
that hot add requests come ordered) we should still keep track of
covered_start_pfn. This is not a revert, the logic is different.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

2017-06-13T13:29:17+00:00

[ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]

The current delay between retries is unnecessarily high and is negatively
affecting the time it takes to boot the system.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Drivers: hv: don't leak memory in vmbus_establish_gpadl()

2017-06-13T13:29:17+00:00

[ Upstream commit 7cc80c98070ccc7940fc28811c92cca0a681015d ]

In some cases create_gpadl_header() allocates submessages but we never
free them.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

drivers: hv: Turn off write permission on the hypercall page

2017-05-17T19:06:58+00:00

[ Upstream commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 ]

The hypercall page only needs to be executable but currently it is setup to
be writable as well. Fix the issue.

Signed-off-by: K. Y. Srinivasan 
Cc: 
Acked-by: Kees Cook 
Reported-by: Stephen Hemminger 
Tested-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

hv: init percpu_list in hv_synic_alloc()

2017-05-16T03:17:20+00:00

[ Upstream commit 3c7630d35009e6635e5b58d62de554fd5b6db5df ]

Initializing hv_context.percpu_list in hv_synic_alloc() helps to prevent a
crash in percpu_channel_enq() when not all CPUs were online during
initialization and it naturally belongs there.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Cc: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

hv: do not lose pending heartbeat vmbus packets

2016-11-24T01:59:49+00:00

[ Upstream commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c ]

The host keeps sending heartbeat packets independent of the
guest responding to them.  Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.

Signed-off-by: Long Li 
Signed-off-by: K. Y. Srinivasan 
CC: Stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin