2016-03-18 13:33+0100, Vitaly Kuznetsov:
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
> from. vmbus_wait_for_unload() doesn't account for the fact that in case
> we're crashing on some other CPU and C
2016-03-18 16:53+0100, Vitaly Kuznetsov:
> Radim Krcmar writes:
>> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>>
>> (I'm not a huge fan of the unloaded variable; what about reme
2016-02-12 16:42+0100, Vitaly Kuznetsov:
> We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context
> and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions
> loops to see if there are new messages pending. In case we'll ever see
> HVMSG_TIMER_EXPIRED message there we
wait instead.
(Too bad we fix crashers, so there is nothing to test on. :])
> Reported-by: Radim Krcmar
Reviewed-by: Radim Krčmář
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/channel_mgmt.c | 4 ++--
> drivers/hv/connection.c | 2 +-
> drivers/hv/hyperv_vmbus.h |
2016-02-12 16:42+0100, Vitaly Kuznetsov:
> We have 3 functions dealing with messages and they all implement
> the same logic to finalize reads, move it to vmbus_signal_eom().
>
> Suggested-by: Radim Krcmar
Reviewed-by: Radim Krčmář
___
d
2016-02-12 16:42+0100, Vitaly Kuznetsov:
> Message header is modified by the hypervisor and we read it in a loop,
> we need to prevent compilers from optimizing accesses. There are no such
> optimizations at this moment, this is just a future proof.
>
> Suggested-by: Radim Krcma
2017-01-19 15:16+0100, Vitaly Kuznetsov:
> With TimeSync version 4 protocol support we started updating system time
> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
> there is a time sample from the host which triggers do_settimeofday[64]().
> While the time from the hos
