Message ID | 20230424082038.541122-1-xenia.ragiadakou@amd.com (mailing list archive) |
---|---|
Headers | show |
Series | hvm: add hvm_funcs hooks for msr intercept handling | expand |
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
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