#
90ac806c |
| 20-Jun-2024 |
Rachel Menge <rachelmenge@linux.microsoft.com> |
Drivers: hv: Remove deprecated hv_fcopy declarations
There are lingering hv_fcopy declarations which do not have definitions. The fcopy driver was removed in commit ec314f61e4fc ("Drivers: hv: Remov
Drivers: hv: Remove deprecated hv_fcopy declarations
There are lingering hv_fcopy declarations which do not have definitions. The fcopy driver was removed in commit ec314f61e4fc ("Drivers: hv: Remove fcopy driver").
Therefore, remove the hv_fcopy declarations which are no longer needed or defined.
Fixes: ec314f61e4fc ("Drivers: hv: Remove fcopy driver") Signed-off-by: Rachel Menge <rachelmenge@linux.microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20240620225040.700563-1-rachelmenge@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20240620225040.700563-1-rachelmenge@linux.microsoft.com>
show more ...
|
#
e8c4bd6c |
| 30-Mar-2024 |
Saurabh Sengar <ssengar@linux.microsoft.com> |
Drivers: hv: vmbus: Add utility function for querying ring size
Add a function to query for the preferred ring buffer size of VMBus device. This will allow the drivers (eg. UIO) to allocate the most
Drivers: hv: vmbus: Add utility function for querying ring size
Add a function to query for the preferred ring buffer size of VMBus device. This will allow the drivers (eg. UIO) to allocate the most optimized ring buffer size for devices.
Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1711788723-8593-2-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
23378295 |
| 24-Aug-2023 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Bring the post_msg_page back for TDX VMs with the paravisor
The post_msg_page was removed in commit 9a6b1a170ca8 ("Drivers: hv: vmbus: Remove the per-CPU post_msg_page")
However
Drivers: hv: vmbus: Bring the post_msg_page back for TDX VMs with the paravisor
The post_msg_page was removed in commit 9a6b1a170ca8 ("Drivers: hv: vmbus: Remove the per-CPU post_msg_page")
However, it turns out that we need to bring it back, but only for a TDX VM with the paravisor: in such a VM, the hyperv_pcpu_input_arg is not decrypted, but the HVCALL_POST_MESSAGE in such a VM needs a decrypted page as the hypercall input page: see the comments in hyperv_init() for a detailed explanation.
Except for HVCALL_POST_MESSAGE and HVCALL_SIGNAL_EVENT, the other hypercalls in a TDX VM with the paravisor still use hv_hypercall_pg and must use the hyperv_pcpu_input_arg (which is encrypted in such a VM), when a hypercall input page is used.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/20230824080712.30327-8-decui@microsoft.com
show more ...
|
#
9a6b1a17 |
| 08-Apr-2023 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Remove the per-CPU post_msg_page
The post_msg_page was introduced in 2014 in commit b29ef3546aec ("Drivers: hv: vmbus: Cleanup hv_post_message()")
Commit 68bb7bfb7985 ("X86/Hype
Drivers: hv: vmbus: Remove the per-CPU post_msg_page
The post_msg_page was introduced in 2014 in commit b29ef3546aec ("Drivers: hv: vmbus: Cleanup hv_post_message()")
Commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments") introduced the hyperv_pcpu_input_arg in 2018, which can be used in hv_post_message().
Remove post_msg_page to simplify the code a little bit.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Jinank Jain <jinankjain@linux.microsoft.com> Link: https://lore.kernel.org/r/20230408213441.15472-1-decui@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
a5ddb745 |
| 26-Mar-2023 |
Michael Kelley <mikelley@microsoft.com> |
Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages
With changes to how Hyper-V guest VMs flip memory between private (encrypted) and shared (decrypted), creating a second kernel virtua
Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages
With changes to how Hyper-V guest VMs flip memory between private (encrypted) and shared (decrypted), creating a second kernel virtual mapping for shared memory is no longer necessary. Everything needed for the transition to shared is handled by set_memory_decrypted().
As such, remove the code to create and manage the second mapping for VMBus monitor pages. Because set_memory_decrypted() and set_memory_encrypted() are no-ops in normal VMs, it's not even necessary to test for being in a Confidential VM (a.k.a., "Isolation VM").
Signed-off-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/1679838727-87310-9-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
52be9355 |
| 11-Jul-2022 |
Shradha Gupta <shradhagupta@linux.microsoft.com> |
Drivers: hv: vm_bus: Handle vmbus rescind calls after vmbus is suspended
Add a flag to indicate that the vmbus is suspended so we should ignore any offer message. Add a new work_queue for rescind ms
Drivers: hv: vm_bus: Handle vmbus rescind calls after vmbus is suspended
Add a flag to indicate that the vmbus is suspended so we should ignore any offer message. Add a new work_queue for rescind msg, so we could drain it along with other offer work_queues upon suspension. It was observed that in some hibernation related scenario testing, after vmbus_bus_suspend() we get rescind offer message for the vmbus. This would lead to processing of a rescind message for a channel that has already been suspended.
Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20220711041147.GA5569@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
b03afa57 |
| 19-Apr-2022 |
Andrea Parri (Microsoft) <parri.andrea@gmail.com> |
Drivers: hv: vmbus: Introduce vmbus_sendpacket_getid()
The function can be used to send a VMbus packet and retrieve the corresponding transaction ID. It will be used by hv_pci.
No functional chang
Drivers: hv: vmbus: Introduce vmbus_sendpacket_getid()
The function can be used to send a VMbus packet and retrieve the corresponding transaction ID. It will be used by hv_pci.
No functional change.
Suggested-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20220419122325.10078-4-parri.andrea@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
de96e8a0 |
| 28-Jan-2022 |
Vitaly Kuznetsov <vkuznets@redhat.com> |
Drivers: hv: Rename 'alloced' to 'allocated'
'Alloced' is not a real word and only saves us two letters, let's use 'allocated' instead.
No functional change intended.
Signed-off-by: Vitaly Kuznets
Drivers: hv: Rename 'alloced' to 'allocated'
'Alloced' is not a real word and only saves us two letters, let's use 'allocated' instead.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20220128103412.3033736-2-vkuznets@redhat.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
f2f136c0 |
| 25-Oct-2021 |
Tianyu Lan <Tianyu.Lan@microsoft.com> |
Drivers: hv: vmbus: Add SNP support for VMbus channel initiate message
The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared with host in Isolation VM and so it's necessary to use hvca
Drivers: hv: vmbus: Add SNP support for VMbus channel initiate message
The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared with host in Isolation VM and so it's necessary to use hvcall to set them visible to host. In Isolation VM with AMD SEV SNP, the access address should be in the extra space which is above shared gpa boundary. So remap these pages into the extra address(pa + shared_gpa_boundary).
Introduce monitor_pages_original[] in the struct vmbus_connection to store monitor page virtual address returned by hv_alloc_hyperv_ zeroed_page() and free monitor page via monitor_pages_original in the vmbus_disconnect(). The monitor_pages[] is to used to access monitor page and it is initialized to be equal with monitor_pages_ original. The monitor_pages[] will be overridden in the isolation VM with va of extra address. Introduce monitor_pages_pa[] to store monitor pages' physical address and use it to populate pa in the initiate msg.
Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20211025122116.264793-9-ltykernel@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
8017c996 |
| 18-Oct-2021 |
Arnd Bergmann <arnd@arndb.de> |
hyperv/vmbus: include linux/bitops.h
On arm64 randconfig builds, hyperv sometimes fails with this error:
In file included from drivers/hv/hv_trace.c:3: In file included from drivers/hv/hyperv_vmbus
hyperv/vmbus: include linux/bitops.h
On arm64 randconfig builds, hyperv sometimes fails with this error:
In file included from drivers/hv/hv_trace.c:3: In file included from drivers/hv/hyperv_vmbus.h:16: In file included from arch/arm64/include/asm/sync_bitops.h:5: arch/arm64/include/asm/bitops.h:11:2: error: only <linux/bitops.h> can be included directly In file included from include/asm-generic/bitops/hweight.h:5: include/asm-generic/bitops/arch_hweight.h:9:9: error: implicit declaration of function '__sw_hweight32' [-Werror,-Wimplicit-function-declaration] include/asm-generic/bitops/atomic.h:17:7: error: implicit declaration of function 'BIT_WORD' [-Werror,-Wimplicit-function-declaration]
Include the correct header first.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211018131929.2260087-1-arnd@kernel.org Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
adae1e93 |
| 08-Apr-2021 |
Andres Beltran <lkmlabelt@gmail.com> |
Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer
Pointers to ring-buffer packets sent by Hyper-V are used within the guest VM. Hyper-V can send packets with erroneous values o
Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer
Pointers to ring-buffer packets sent by Hyper-V are used within the guest VM. Hyper-V can send packets with erroneous values or modify packet fields after they are processed by the guest. To defend against these scenarios, return a copy of the incoming VMBus packet after validating its length and offset fields in hv_pkt_iter_first(). In this way, the packet can no longer be modified by the host.
Signed-off-by: Andres Beltran <lkmlabelt@gmail.com> Co-developed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20210408161439.341988-1-parri.andrea@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
5c641fee |
| 06-Dec-2020 |
Stefan Eschenbacher <stefan.eschenbacher@fau.de> |
drivers/hv: remove obsolete TODO and fix misleading typo in comment
Removes an obsolete TODO in the VMBus module and fixes a misleading typo in the comment for the macro MAX_NUM_CHANNELS, where two
drivers/hv: remove obsolete TODO and fix misleading typo in comment
Removes an obsolete TODO in the VMBus module and fixes a misleading typo in the comment for the macro MAX_NUM_CHANNELS, where two digits have been twisted.
Signed-off-by: Stefan Eschenbacher <stefan.eschenbacher@fau.de> Co-developed-by: Max Stolze <max.stolze@fau.de> Signed-off-by: Max Stolze <max.stolze@fau.de> Link: https://lore.kernel.org/r/20201206104850.24843-1-stefan.eschenbacher@fau.de Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
e8b7db38 |
| 09-Nov-2020 |
Andres Beltran <lkmlabelt@gmail.com> |
Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening
Currently, VMbus drivers use pointers into guest memory as request IDs for interactions with Hyper-V. To be more robust in
Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening
Currently, VMbus drivers use pointers into guest memory as request IDs for interactions with Hyper-V. To be more robust in the face of errors or malicious behavior from a compromised Hyper-V, avoid exposing guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a bad request ID that is then treated as the address of a guest data structure with no validation. Instead, encapsulate these memory addresses and provide small integers as request IDs.
Signed-off-by: Andres Beltran <lkmlabelt@gmail.com> Co-developed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/20201109100402.8946-2-parri.andrea@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
afaa33da |
| 22-May-2020 |
Andrea Parri (Microsoft) <parri.andrea@gmail.com> |
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the CPUs allocated for channel interrupts at a given time, and dist
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the CPUs allocated for channel interrupts at a given time, and distribute the performance-critical channels across the available CPUs: in part., the mask of "candidate" target CPUs in a given NUMA node, for a newly offered channel, is determined by XOR-ing the node's CPU mask and the node's hv_numa_map. This operation/mechanism assumes that no offline CPUs is set in the hv_numa_map mask, an assumption that does not hold since such mask is currently not updated when a channel is removed or assigned to a different CPU.
To address the issues described above, this adds hooks in the channel removal path (hv_process_channel_removal()) and in target_cpu_store() in order to clear, resp. to update, the hv_numa_map[] masks as needed. This also adds a (missed) update of the masks in init_vp_index() (cf., e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine if the given channel is performance critical. init_vp_index() does this by parsing the channel's offer, it can not rely on the device data structure (device_obj) to retrieve such information because the device data structure has not been allocated/linked with the channel by the time that init_vp_index() executes. A similar situation may hold in hv_is_alloced_cpu() (defined below); the adopted approach is to "cache" the device type of the channel, as computed by parsing the channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type") Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
238d2ed8 |
| 06-Apr-2020 |
Andrea Parri (Microsoft) <parri.andrea@gmail.com> |
hv_utils: Always execute the fcopy and vss callbacks in a tasklet
The fcopy and vss callback functions could be running in a tasklet at the same time they are called in hv_poll_channel(). Current c
hv_utils: Always execute the fcopy and vss callbacks in a tasklet
The fcopy and vss callback functions could be running in a tasklet at the same time they are called in hv_poll_channel(). Current code serializes the invocations of these functions, and their accesses to the channel ring buffer, by sending an IPI to the CPU that is allowed to access the ring buffer, cf. hv_poll_channel(). This IPI mechanism becomes infeasible if we allow changing the CPU that a channel will interrupt. Instead modify the callback wrappers to always execute the fcopy and vss callbacks in a tasklet, thus mirroring the solution for the kvp callback functions adopted since commit a3ade8cc474d8 ("HV: properly delay KVP packets when negotiation is in progress"). This will ensure that the callback function can't run on two CPUs at the same time.
Suggested-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20200406001514.19876-6-parri.andrea@gmail.com Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
8b6a877c |
| 06-Apr-2020 |
Andrea Parri (Microsoft) <parri.andrea@gmail.com> |
Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels
When Hyper-V sends an interrupt to the guest, the guest has to figure out which channel the interrupt is associa
Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels
When Hyper-V sends an interrupt to the guest, the guest has to figure out which channel the interrupt is associated with. Hyper-V sets a bit in a memory page that is shared with the guest, indicating a particular "relid" that the interrupt is associated with. The current Linux code then uses a set of per-CPU linked lists to map a given "relid" to a pointer to a channel structure.
This design introduces a synchronization problem if the CPU that Hyper-V will interrupt for a certain channel is changed. If the interrupt comes on the "old CPU" and the channel was already moved to the per-CPU list of the "new CPU", then the relid -> channel mapping will fail and the interrupt is dropped. Similarly, if the interrupt comes on the new CPU but the channel was not moved to the per-CPU list of the new CPU, then the mapping will fail and the interrupt is dropped.
Relids are integers ranging from 0 to 2047. The mapping from relids to channel structures can be done by setting up an array with 2048 entries, each entry being a pointer to a channel structure (hence total size ~16K bytes, which is not a problem). The array is global, so there are no per-CPU linked lists to update. The array can be searched and updated by loading from/storing to the array at the specified index. With no per-CPU data structures, the above mentioned synchronization problem is avoided and the relid2channel() function gets simpler.
Suggested-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20200406001514.19876-4-parri.andrea@gmail.com Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
8a857c55 |
| 06-Apr-2020 |
Andrea Parri (Microsoft) <parri.andrea@gmail.com> |
Drivers: hv: vmbus: Always handle the VMBus messages on CPU0
A Linux guest have to pick a "connect CPU" to communicate with the Hyper-V host. This CPU can not be taken offline because Hyper-V does
Drivers: hv: vmbus: Always handle the VMBus messages on CPU0
A Linux guest have to pick a "connect CPU" to communicate with the Hyper-V host. This CPU can not be taken offline because Hyper-V does not provide a way to change that CPU assignment.
Current code sets the connect CPU to whatever CPU ends up running the function vmbus_negotiate_version(), and this will generate problems if that CPU is taken offine.
Establish CPU0 as the connect CPU, and add logics to prevents the connect CPU from being taken offline. We could pick some other CPU, and we could pick that "other CPU" dynamically if there was a reason to do so at some point in the future. But for now, #defining the connect CPU to 0 is the most straightforward and least complex solution.
While on this, add inline comments explaining "why" offer and rescind messages should not be handled by a same serialized work queue.
Suggested-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20200406001514.19876-2-parri.andrea@gmail.com Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
52c7803f |
| 06-Apr-2020 |
Vitaly Kuznetsov <vkuznets@redhat.com> |
Drivers: hv: check VMBus messages lengths
VMBus message handlers (channel_message_table) receive a pointer to 'struct vmbus_channel_message_header' and cast it to a structure of their choice, which
Drivers: hv: check VMBus messages lengths
VMBus message handlers (channel_message_table) receive a pointer to 'struct vmbus_channel_message_header' and cast it to a structure of their choice, which is sometimes longer than the header. We, however, don't check that the message is long enough so in case hypervisor screws up we'll be accessing memory beyond what was allocated for temporary buffer.
Previously, we used to always allocate and copy 256 bytes from message page to temporary buffer but this is hardly better: in case the message is shorter than we expect we'll be trying to consume garbage as some real data and no memory guarding technique will be able to identify an issue.
Introduce 'min_payload_len' to 'struct vmbus_channel_message_table_entry' and check against it in vmbus_on_msg_dpc(). Note, we can't require the exact length as new hypervisor versions may add extra fields to messages, we only check that the message is not shorter than we expect.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20200406104326.45361-1-vkuznets@redhat.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
032d4a48 |
| 19-Mar-2020 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
hv: hyperv_vmbus.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism t
hv: hyperv_vmbus.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };
By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
show more ...
|
#
54e19d34 |
| 26-Jan-2020 |
Dexuan Cui <decui@microsoft.com> |
hv_utils: Add the support of hibernation
Add util_pre_suspend() and util_pre_resume() for some hv_utils devices (e.g. kvp/vss/fcopy), because they need special handling before util_suspend() calls v
hv_utils: Add the support of hibernation
Add util_pre_suspend() and util_pre_resume() for some hv_utils devices (e.g. kvp/vss/fcopy), because they need special handling before util_suspend() calls vmbus_close().
For kvp, all the possible pending work items should be cancelled.
For vss and fcopy, some extra clean-up needs to be done, i.e. fake a THAW message for hv_vss_daemon and fake a CANCEL_FCOPY message for hv_fcopy_daemon, otherwise when the VM resums back, the daemons can end up in an inconsistent state (i.e. the file systems are frozen but will never be thawed; the file transmitted via fcopy may not be complete). Note: there is an extra patch for the daemons: "Tools: hv: Reopen the devices if read() or write() returns errors", because the hv_utils driver can not guarantee the whole transaction finishes completely once util_suspend() starts to run (at this time, all the userspace processes are frozen).
util_probe() disables channel->callback_event to avoid the race with the channel callback.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
af9ca6f9 |
| 03-Oct-2019 |
Branden Bonaby <brandonbonaby94@gmail.com> |
drivers: hv: vmbus: Introduce latency testing
Introduce user specified latency in the packet reception path By exposing the test parameters as part of the debugfs channel attributes. We will control
drivers: hv: vmbus: Introduce latency testing
Introduce user specified latency in the packet reception path By exposing the test parameters as part of the debugfs channel attributes. We will control the testing state via these attributes.
Signed-off-by: Branden Bonaby <brandonbonaby94@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d8bd2d44 |
| 05-Sep-2019 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Resume after fixing up old primary channels
When the host re-offers the primary channels upon resume, the host only guarantees the Instance GUID doesn't change, so vmbus_bus_sus
Drivers: hv: vmbus: Resume after fixing up old primary channels
When the host re-offers the primary channels upon resume, the host only guarantees the Instance GUID doesn't change, so vmbus_bus_suspend() should invalidate channel->offermsg.child_relid and figure out the number of primary channels that need to be fixed up upon resume.
Upon resume, vmbus_onoffer() finds the old channel structs, and maps the new offers to the old channels, and fixes up the old structs, and finally the resume callbacks of the VSC drivers will re-open the channels.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b307b389 |
| 05-Sep-2019 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels
Before suspend, Linux must make sure all the hv_sock channels have been properly cleaned up, because a hv_sock connection can n
Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels
Before suspend, Linux must make sure all the hv_sock channels have been properly cleaned up, because a hv_sock connection can not persist across hibernation, and the user-space app must be properly notified of the state change of the connection.
Before suspend, Linux also must make sure all the sub-channels have been destroyed, i.e. the related channel structs of the sub-channels must be properly removed, otherwise they would cause a conflict when the sub-channels are recreated upon resume.
Add a counter to track such channels, and vmbus_bus_suspend() should wait for the counter to drop to zero.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
f53335e3 |
| 05-Sep-2019 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation
Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to the host so all the offers are gone. After hibernation,
Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation
Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to the host so all the offers are gone. After hibernation, Linux needs to re-negotiate with the host using the same vmbus protocol version (which was in use before hibernation), and ask the host to re-offer the vmbus devices.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
dba61cda |
| 05-Sep-2019 |
Dexuan Cui <decui@microsoft.com> |
Drivers: hv: vmbus: Break out synic enable and disable operations
Break out synic enable and disable operations into separate hv_synic_disable_regs() and hv_synic_enable_regs() functions for use by
Drivers: hv: vmbus: Break out synic enable and disable operations
Break out synic enable and disable operations into separate hv_synic_disable_regs() and hv_synic_enable_regs() functions for use by a later patch to support hibernation.
There is no functional change except the unnecessary check "if (sctrl.enable != 1) return -EFAULT;" which is removed, because when we're in hv_synic_cleanup(), we're absolutely sure sctrl.enable must be 1.
Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|