RE: [PATCH V6 7/8] Drivers: hv: vmbus: Add SNP support for VMbus channel initiate message
From: Michael Kelley <hidden>
Date: 2021-10-04 02:40:07
Also in:
linux-arch, lkml, netdev
From: Michael Kelley <hidden>
Date: 2021-10-04 02:40:07
Also in:
linux-arch, lkml, netdev
From: Tianyu Lan <redacted> Sent: Saturday, October 2, 2021 7:40 AM
On 10/2/2021 9:26 PM, Michael Kelley wrote:quoted
quoted
@@ -303,10 +365,26 @@ void vmbus_disconnect(void) vmbus_connection.int_page = NULL; } - hv_free_hyperv_page((unsigned long)vmbus_connection.monitor_pages[0]); - hv_free_hyperv_page((unsigned long)vmbus_connection.monitor_pages[1]); - vmbus_connection.monitor_pages[0] = NULL; - vmbus_connection.monitor_pages[1] = NULL; + if (hv_is_isolation_supported()) { + memunmap(vmbus_connection.monitor_pages[0]); + memunmap(vmbus_connection.monitor_pages[1]);The matching memremap() calls are made in vmbus_connect() only in the SNP case. In the non-SNP case, monitor_pages and monitor_pages_original are the same, so you would be doing an unmap, and then doing the set_memory_encrypted() and hv_free_hyperv_page() using an address that is no longer mapped, which seems wrong. Looking at memunmap(), it might be a no-op in this case, but even if it is, making them conditional on the SNP case might be a safer thing to do, and it would make the code more symmetrical.Yes, memumap() does nothing is the non-SNP CVM and so I didn't check CVM type here. I will add the check in the next version. Thanks.
I would also be OK with just adding a comment to that effect, just so someone looking at the code in the future understands that there's not a problem. Your call. Michael