search for: hv_x64_msr_hypercall

...>> > When Linux is running as the root partition, the hypercall page will >> > have already been setup by Hyper-V. Copy the content over to the >> > allocated page. >> >> And we can't setup a new hypercall page by writing something different >> to HV_X64_MSR_HYPERCALL, right? >> > > My understanding is that we can't, but Sunil can maybe correct me. > >> > >> > The suspend, resume and cleanup paths remain untouched because they are >> > not supported in this setup yet. >> > >> > Signed-off-by: Lilli...

...root partition, the hypercall page will >> >> > have already been setup by Hyper-V. Copy the content over to the >> >> > allocated page. >> >> >> >> And we can't setup a new hypercall page by writing something different >> >> to HV_X64_MSR_HYPERCALL, right? >> >> >> > >> > My understanding is that we can't, but Sunil can maybe correct me. >> > >> >> > >> >> > The suspend, resume and cleanup paths remain untouched because they are >> >> > not supported in t...

Wei Liu <wei.liu at kernel.org> writes: > When Linux is running as the root partition, the hypercall page will > have already been setup by Hyper-V. Copy the content over to the > allocated page. And we can't setup a new hypercall page by writing something different to HV_X64_MSR_HYPERCALL, right? > > The suspend, resume and cleanup paths remain untouched because they are > not supported in this setup yet. > > Signed-off-by: Lillian Grassin-Drake <ligrassi at microsoft.com> > Signed-off-by: Sunil Muthuswamy <sunilmut at microsoft.com> > Signed-off-by...

...; > > When Linux is running as the root partition, the hypercall page will > > > have already been setup by Hyper-V. Copy the content over to the > > > allocated page. > > > > And we can't setup a new hypercall page by writing something different > > to HV_X64_MSR_HYPERCALL, right? > > > > My understanding is that we can't, but Sunil can maybe correct me. That is correct. For root partition, the hypervisor has already allocated the hypercall page. The root is required to query the page, map it in its address space and wrmsr to enable it. It cannot ch...

...& 0xFFFFFFFF; - volatile void *hypercallPage = gHvContext.HypercallPage; + volatile void *hypercallPage = g_hv_context.hypercall_page; DPRINT_DBG(VMBUS, "Hypercall <control %llx input %p output %p>", Control, Input, Output); @@ -192,8 +192,9 @@ int HvInit(void) union hv_x64_msr_hypercall_contents hypercallMsr; void *virtAddr = NULL; - memset(gHvContext.synICEventPage, 0, sizeof(void *) * MAX_NUM_CPUS); - memset(gHvContext.synICMessagePage, 0, sizeof(void *) * MAX_NUM_CPUS); + memset(g_hv_context.synic_event_page, 0, sizeof(void *) * MAX_NUM_CPUS); + memset(g_hv_context.synic_me...

...& 0xFFFFFFFF; - volatile void *hypercallPage = gHvContext.HypercallPage; + volatile void *hypercallPage = g_hv_context.hypercall_page; DPRINT_DBG(VMBUS, "Hypercall <control %llx input %p output %p>", Control, Input, Output); @@ -192,8 +192,9 @@ int HvInit(void) union hv_x64_msr_hypercall_contents hypercallMsr; void *virtAddr = NULL; - memset(gHvContext.synICEventPage, 0, sizeof(void *) * MAX_NUM_CPUS); - memset(gHvContext.synICMessagePage, 0, sizeof(void *) * MAX_NUM_CPUS); + memset(g_hv_context.synic_event_page, 0, sizeof(void *) * MAX_NUM_CPUS); + memset(g_hv_context.synic_me...

From: Haiyang Zhang <haiyangz at microsoft.com> Convert camel cased struct fields in channel_mgmt.h to lower cases Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/channel.c | 302 ++++++++++++++++++------------------ drivers/staging/hv/channel_mgmt.c | 186 ++++++++++++------------

From: Haiyang Zhang <haiyangz at microsoft.com> Convert camel cased struct fields in channel_mgmt.h to lower cases Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/channel.c | 302 ++++++++++++++++++------------------ drivers/staging/hv/channel_mgmt.c | 186 ++++++++++++------------

This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. All DPRINT calls have been removed, and where needed have been replaced with pr_XX native calls. Many debug DPRINT calls have been removed outright. The amount of clutter this driver prints has been significantly reduced. Signed-off-by: Hank Janssen <hjanssen at microsoft.com>

This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. All DPRINT calls have been removed, and where needed have been replaced with pr_XX native calls. Many debug DPRINT calls have been removed outright. The amount of clutter this driver prints has been significantly reduced. Signed-off-by: Hank Janssen <hjanssen at microsoft.com>

The 6-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. one MSR is added to aid live migration. Changes

The 6-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. one MSR is added to aid live migration. Changes

This patch set removes all un-needed DPRINT and printk calls and replaces the remaining ones with the correct pr_, dev_ and netdev_ calls from hv_vmbus, hv_netvsc, hv_timesource and hv_utils. Several DPRINTS are remaining that will be cleaned up in my next set of patches. They deal with printing out certain debugging that will be implemented slightly differently. The remaining hv_storvsc and

This patch set removes all un-needed DPRINT and printk calls and replaces the remaining ones with the correct pr_, dev_ and netdev_ calls from hv_vmbus, hv_netvsc, hv_timesource and hv_utils. Several DPRINTS are remaining that will be cleaned up in my next set of patches. They deal with printing out certain debugging that will be implemented slightly differently. The remaining hv_storvsc and

Further cleanup of the hv drivers. 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across the board and use standard Linux error codes. 3) General cleanup Regards, K. Y

Further cleanup of the hv drivers. 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across the board and use standard Linux error codes. 3) General cleanup Regards, K. Y

Further cleanup of the hv drivers. Back in June I had sent two patch sets to address these issues. I have addressed the comments I got from the community on my earlier patches here: 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across

Further cleanup of the hv drivers. Back in June I had sent two patch sets to address these issues. I have addressed the comments I got from the community on my earlier patches here: 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across