This will be useful when invoking hypercall that targets specific
vcpu(s).

Signed-off-by: Wei Liu <liuwe@microsoft.com>
Reviewed-by: Paul Durrant <paul@xen.org>
---
v4:
1. Use private.h
2. Add Paul's review tag

v2:
1. Fold into setup_pcpu_arg function
---
 xen/arch/x86/guest/hyperv/hyperv.c  | 5 +++++
 xen/arch/x86/guest/hyperv/private.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
index c5195af948..085e646dc6 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -31,6 +31,7 @@
 
 struct ms_hyperv_info __read_mostly ms_hyperv;
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_arg);
+DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
 static uint64_t generate_guest_id(void)
 {
@@ -125,6 +126,7 @@ static void __init setup_hypercall_page(void)
 static void setup_hypercall_pcpu_arg(void)
 {
     void *mapping;
+    uint64_t vp_index_msr;
 
     if ( this_cpu(hv_pcpu_input_arg) )
         return;
@@ -135,6 +137,9 @@ static void setup_hypercall_pcpu_arg(void)
               smp_processor_id());
 
     this_cpu(hv_pcpu_input_arg) = mapping;
+
+    rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
+    this_cpu(hv_vp_index) = vp_index_msr;
 }
 
 static void __init setup(void)
diff --git a/xen/arch/x86/guest/hyperv/private.h b/xen/arch/x86/guest/hyperv/private.h
index b6902b5639..da70990401 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -25,5 +25,6 @@
 #include <xen/percpu.h>
 
 DECLARE_PER_CPU(void *, hv_pcpu_input_arg);
+DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
 #endif /* __XEN_HYPERV_PRIVIATE_H__  */
-- 
2.20.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On 22.01.2020 21:23, Wei Liu wrote:
> This will be useful when invoking hypercall that targets specific
> vcpu(s).
> 
> Signed-off-by: Wei Liu <liuwe@microsoft.com>
> Reviewed-by: Paul Durrant <paul@xen.org>

For formal reasons
Acked-by: Jan Beulich <jbeulich@suse.com>

However I wonder whether the Viridian entry in MAINTAINERS shouldn't
be extended by

F:	xen/arch/x86/guest/hyperv/

(and possibly have its title adjusted). Thoughts?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On Thu, Jan 23, 2020 at 04:48:38PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > This will be useful when invoking hypercall that targets specific
> > vcpu(s).
> > 
> > Signed-off-by: Wei Liu <liuwe@microsoft.com>
> > Reviewed-by: Paul Durrant <paul@xen.org>
> 
> For formal reasons
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> However I wonder whether the Viridian entry in MAINTAINERS shouldn't
> be extended by
> 
> F:	xen/arch/x86/guest/hyperv/
> 
> (and possibly have its title adjusted). Thoughts?

This isn't about emulating Hyper-V inside Xen, so I don't think that's
the right approach here.

That said, if Paul wants to take this under his purview, it's fine by me
-- that would make me easier to upstream my patch. ;-)  I also wouldn't
mind adding myself as maintainer for this path.

Wei.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

On 28.01.2020 16:55, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 04:48:38PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> This will be useful when invoking hypercall that targets specific
>>> vcpu(s).
>>>
>>> Signed-off-by: Wei Liu <liuwe@microsoft.com>
>>> Reviewed-by: Paul Durrant <paul@xen.org>
>>
>> For formal reasons
>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>
>> However I wonder whether the Viridian entry in MAINTAINERS shouldn't
>> be extended by
>>
>> F:	xen/arch/x86/guest/hyperv/
>>
>> (and possibly have its title adjusted). Thoughts?
> 
> This isn't about emulating Hyper-V inside Xen, so I don't think that's
> the right approach here.

Well, it's the code producing the interface in one case, and
consuming it here. So there is some overlap at least.

> That said, if Paul wants to take this under his purview, it's fine by me
> -- that would make me easier to upstream my patch. ;-)  I also wouldn't
> mind adding myself as maintainer for this path.

Perhaps best both of you? Paul, Andrew, what do you think?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel