- 02 Mar, 2015 40 commits
-
-
Tomas Winkler authored
call device's disable handler prior to disconnection so it can possibly close the communication with fw client in graceful way Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Winkler authored
Replace clunky read state machine with read stack implemented as per client read list, this is important mostly for mei drivers with unsolicited reads Signed-off-by:
-
Tomas Winkler authored
Simplify disposal of io callback by removing the callback implicitly from its lookup list inside mei_io_cb_free Signed-off-by:
-
Tomas Winkler authored
Add convenient wrapper mei_cl_alloc_linked to simplify error handling Signed-off-by:
-
Tomas Winkler authored
We set the operation type at initialization time as each cb is used only for a single type of operation As a byproduct we add a convenient wrapper for allocating cb with the data buffer. Signed-off-by:
-
Tomas Winkler authored
The callback structure is used exclusively for reading or writing therefore there is no reason to hold both response and request buffers in the callback structure Signed-off-by:
-
Tomas Winkler authored
Reduce code duplication in amthif by reusing regular client read functions. The change also removes the need for amthif own buffering Signed-off-by:
-
Tomas Winkler authored
Reduce code duplication in amthif code by reusing regular client write functions. Add completed flag to cb so amthif client can add rx credits on write completion Signed-off-by:
-
Tomas Winkler authored
Reuse common client mechanism for sending flow control hbm message. Add new function mei_amthif_read_start similar to mei_cl_read_start that puts control flow request onto the control write queue and drop mei_amthif_irq_read function Signed-off-by:
-
Tomas Winkler authored
iamthif_ioctl is obsolete and can be safely dropped Currently it is set to true during driver runtime Signed-off-by:
-
Tomas Winkler authored
On failure mei_amthif_irq_read_msg returns an error that will cause device reset but the issue is software one so instead we should propagate error to caller and just clean the read queues. As a side effect also removes useless BUG_ONs Signed-off-by:
-
Tomas Winkler authored
On memory allocation failure mei_cl_irq_read_msg will return with error that will cause device reset. Instead we should propagate error to caller and just clean the read queues. Signed-off-by:
-
Alexander Usyskin authored
Align functions names in KDoc with real ones. Fix comment format to be KDoc and fix wrong syntax there. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
-
Alexander Usyskin authored
The current power gating naming was confusing, we wish to swap meanings of register and flow level power gating terms, For registers writing level use terms set and unset: mei_me_pg_set, mei_me_pg_unset For flow/high level use power gating enter and power gating exit terms mei_me_pg_enter_sync, mei_me_pg_exit_sync Signed-off-by:
-
Tomas Winkler authored
To make debugging a bit easier we add me register access tracing <debugfs>/tracing/events/mei/mei_reg_{read,write} Signed-off-by: -
Tomas Winkler authored
1. Use mei_device structure as the first argument to the io register access wrappers so we'll have access to the device structure needed for tracing. 2. Use wrapper consistently Signed-off-by:
-
Tomas Winkler authored
1. Use rw lock to access the me_clients list 2. Reuse already defined find functions also when removing particular me client 3. Add wrappers for addition and deletion Signed-off-by:
-
K. Y. Srinivasan authored
Implement an API that gives additional control on the what VMBUS flags will be set as well as if the host needs to be signalled. This API will be useful for clients that want to batch up requests to the host. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
Implement an API for sending pagebuffers that gives more control to the client in terms of setting the vmbus flags as well as deciding when to notify the host. This will be useful for enabling batch processing. Signed-off-by:
-
K. Y. Srinivasan authored
The current algorithm for picking an outgoing channel was not distributing the load well. Implement a simple round-robin scheme to ensure good distribution of the outgoing traffic. Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
-
Nick Meier authored
Hyper-V allows a guest to notify the Hyper-V host that a panic condition occured. This notification can include up to five 64 bit values. These 64 bit values are written into crash MSRs. Once the data has been written into the crash MSRs, the host is then notified by writing into a Crash Control MSR. On the Hyper-V host, the panic notification data is captured in the Windows Event log as a 18590 event. Crash MSRs are defined in appendix H of the Hypervisor Top Level Functional Specification. At the time of this patch, v4.0 is the current functional spec. The URL for the v4.0 document is: http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor Top Level Functional Specification v4.0.docx Signed-off-by:
Nick Meier <nmeier@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
When host asks us to balloon up we need to be sure we're not committing suicide by overballooning. Use already existent 'floor' metric as our lowest possible value for free ram. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
When hot-added memory pages are not brought online or when some memory blocks are sent offline the subsequent ballooning process kills the guest with OOM killer. This happens as we don't report these pages as neither used nor free and apparently host algorithm considers them as being unused. Keep track of all online/offline operations and report all currently offline pages as being used so host won't try to balloon them out. Signed-off-by:
-
Vitaly Kuznetsov authored
When many memory regions are being added and automatically onlined the following lockup is sometimes observed: INFO: task udevd:1872 blocked for more than 120 seconds. ... Call Trace: [<ffffffff816ec0bc>] schedule_timeout+0x22c/0x350 [<ffffffff816eb98f>] wait_for_common+0x10f/0x160 [<ffffffff81067650>] ? default_wake_function+0x0/0x20 [<ffffffff816eb9fd>] wait_for_completion+0x1d/0x20 [<ffffffff8144cb9c>] hv_memory_notifier+0xdc/0x120 [<ffffffff816f298c>] notifier_call_chain+0x4c/0x70 ... When several memory blocks are going online simultaneously we got several hv_memory_notifier() trying to acquire the ha_region_mutex. When this mutex is being held by hot_add_req() all these competing acquire_region_mutex() do mutex_trylock, fail, and queue themselves into wait_for_completion(..). However when we do complete() from release_region_mutex() only one of them wakes up. This could be solved by changing complete() -> complete_all() memory onlining can be delayed as well, in that case we can still get several hv_memory_notifier() runners at the same time trying to grab the mutex. Only one of them will succeed and the others will hang for forever as complete() is not being called. We don't see this issue often because we have 5sec onlining timeout in hv_mem_hot_add() and usually all udev events arrive in this time frame. Get rid of the trylock path, waiting on the mutex is supposed to provide the required serialization. Signed-off-by:
-
K. Y. Srinivasan authored
Currently we log messages when either we are not able to map an ID to a channel or when the channel does not have a callback associated (in the channel interrupt handling path). These messages don't add any value, get rid of them. Signed-off-by:
-
K. Y. Srinivasan authored
When the offer is rescinded, vmbus_close() can free up the channel; deinitialize the service before closing the channel. Signed-off-by:
-
K. Y. Srinivasan authored
Properly rollback state in vmbus_pocess_offer() in the failure paths. Signed-off-by:
-
K. Y. Srinivasan authored
Execute both ressind and offer messages in the same work context. This serializes these operations and naturally addresses the various corner cases. Signed-off-by:
-
K. Y. Srinivasan authored
In response to a rescind message, we need to remove the channel and the corresponding device. Cleanup this code path by factoring out the code to remove a channel. Signed-off-by:
-
K. Y. Srinivasan authored
Handle the case when the device may be removed when the device has no driver attached to it. Signed-off-by:
-
K. Y. Srinivasan authored
NetworkDirect is a service that supports guest RDMA. Define the GUID for this service. Signed-off-by:
-
K. Y. Srinivasan authored
Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by:
-
Nicholas Mc Guire authored
return type of wait_for_completion_timeout is unsigned long not int, this patch changes the type of t from int to unsigned long. Signed-off-by:
Nicholas Mc Guire <der.herr@hofr.at> Signed-off-by:
-
Nicholas Mc Guire authored
return type of wait_for_completion_timeout is unsigned long not int, this patch changes the type of t from int to unsigned long. Signed-off-by:
-
Nicholas Mc Guire authored
return type of wait_for_completion_timeout is unsigned long not int, this patch changes the type of t from int to unsigned long. Signed-off-by:
-
Dexuan Cui authored
Without this patch, the state is put to CHANNEL_OPENING_STATE, and when the driver is loaded next time, vmbus_open() will fail immediately due to newchannel->state != CHANNEL_OPEN_STATE. CC: "K. Y. Srinivasan" <kys@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Dexuan Cui authored
I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping running "rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe hv_utils" in a Linux guest. Looks the host has some kind of throttling mechanism if some kinds of hypercalls are sent too frequently. Without the patch, the driver can occasionally fail to load. Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get it before. Removed 'case -ENOMEM', since the hypervisor doesn't return this. CC: "K. Y. Srinivasan" <kys@microsoft.com> Reviewed-by:
-
Dexuan Cui authored
Before the line vmbus_open() returns, srv->util_cb can be already running and the variables, like util_fw_version, are needed by the srv->util_cb. So we have to make sure the variables are initialized before the vmbus_open(). CC: "K. Y. Srinivasan" <kys@microsoft.com> Reviewed-by:
-
Vitaly Kuznetsov authored
Newly introduced clockevent devices made it impossible to unload hv_vmbus module as clockevents_config_and_register() takes additional reverence to the module. To make it possible again we do the following: - avoid setting dev->owner for clockevent devices; - implement hv_synic_clockevents_cleanup() doing clockevents_unbind_device(); - call it from vmbus_exit(). In theory hv_synic_clockevents_cleanup() can be merged with hv_synic_cleanup(), however, we call hv_synic_cleanup() from smp_call_function_single() and this doesn't work for clockevents_unbind_device() as it does such call on its own. I opted for a separate function. Signed-off-by:
-
Vitaly Kuznetsov authored
It looks like clockevents_unbind is being exported by mistake as: - it is static; - it is not listed in include/linux/clockchips.h; - EXPORT_SYMBOL_GPL(clockevents_unbind) follows clockevents_unbind_device() implementation. I think clockevents_unbind_device should be exported instead. This is going to be used to teardown Hyper-V clockevent devices on module unload. Signed-off-by:
-
