This patch series aims to make the msr intercept handling, performed in
vpmu code, virtualization technology agnostic.
It creates a common interface for setting/clearing the msr intercepts and
then add hooks to the corresponding hvm_funcs table to be able to call the
svm/vmx specific handlers through a generic hvm wrapper function.

Version 2 addresses the comments made on version 1 to ease further review.

Still there is a pending question made by Jan, whether there could be other,
than the vpmu one, use cases that would require msr intercept handling to be
performed outside of virtualization techonology-specific code, and whether
this abstraction is actually usefull to have.

Xenia Ragiadakou (3):
  x86/svm: split svm_intercept_msr() into
    svm_{set,clear}_msr_intercept()
  x86/vmx: replace enum vmx_msr_intercept_type with the msr access flags
  x86/hvm: create hvm_funcs for {svm,vmx}_{set,clear}_msr_intercept()

 xen/arch/x86/cpu/vpmu_amd.c             |  9 +--
 xen/arch/x86/cpu/vpmu_intel.c           | 24 ++++----
 xen/arch/x86/hvm/svm/svm.c              | 75 ++++++++++++++++---------
 xen/arch/x86/hvm/vmx/vmcs.c             | 40 ++++++-------
 xen/arch/x86/hvm/vmx/vmx.c              | 46 +++++++--------
 xen/arch/x86/include/asm/hvm/hvm.h      | 34 +++++++++++
 xen/arch/x86/include/asm/hvm/svm/vmcb.h | 15 ++---
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 16 ++----
 8 files changed, 155 insertions(+), 104 deletions(-)

-- 
2.34.1

On 24.04.2023 10:20, Xenia Ragiadakou wrote:
> This patch series aims to make the msr intercept handling, performed in
> vpmu code, virtualization technology agnostic.
> It creates a common interface for setting/clearing the msr intercepts and
> then add hooks to the corresponding hvm_funcs table to be able to call the
> svm/vmx specific handlers through a generic hvm wrapper function.
> 
> Version 2 addresses the comments made on version 1 to ease further review.
> 
> Still there is a pending question made by Jan, whether there could be other,
> than the vpmu one, use cases that would require msr intercept handling to be
> performed outside of virtualization techonology-specific code, and whether
> this abstraction is actually usefull to have.
> 
> Xenia Ragiadakou (3):
>   x86/svm: split svm_intercept_msr() into
>     svm_{set,clear}_msr_intercept()
>   x86/vmx: replace enum vmx_msr_intercept_type with the msr access flags
>   x86/hvm: create hvm_funcs for {svm,vmx}_{set,clear}_msr_intercept()

Coming back to this after discussing among the maintainers; I'm sorry that
it has taken a while. For what the 1st patch does we think we might be more
open to a conversion of VMX code in the direction of how SVM presently does
things. Andrew points out, however, that he's suspecting there may be a
wrinkle with introspection, which likely we'd need to work out collectively.

As far as the introduction of new hooks (or maybe then only one new hook)
goes, are you having further plans of using those hooks, beyond (iirc)
possibly using them in vPMU code (where I continue to think hooks aren't
really suitable, as per-vendor code is already separated)? According to
what you wrote above it doesn't sound like you do.

Jan

On 24.04.2023 10:20, Xenia Ragiadakou wrote:
> This patch series aims to make the msr intercept handling, performed in
> vpmu code, virtualization technology agnostic.
> It creates a common interface for setting/clearing the msr intercepts and
> then add hooks to the corresponding hvm_funcs table to be able to call the
> svm/vmx specific handlers through a generic hvm wrapper function.
> 
> Version 2 addresses the comments made on version 1 to ease further review.
> 
> Still there is a pending question made by Jan, whether there could be other,
> than the vpmu one, use cases that would require msr intercept handling to be
> performed outside of virtualization techonology-specific code, and whether
> this abstraction is actually usefull to have.

Just for reference: The code changes look okay to me now. They could get my
ack, provided we really want to go this route (which I continue to be
unconvinced of).

Jan