Re: [Xen-devel] [PATCH v1 0/5] Generic MSR policy: infrastructure + cpuid_faulting

[Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>]

Ping?

On Wed, 2017-08-30 at 11:34 +0100, Sergey Dyasli wrote:
> Currently there are the following issues with handling guest's RD/WRMSR
> in Xen:
> 
> 1. There is no way to configure which MSRs a guest can and can't access.
>    And if there is no MSR handler in Xen for a particular MSR then
>    the default behavior is just horrible:
> 
>         RDMSR: rdmsr_safe(msr, *msr_content) /* returns a H/W value */
>         WRMSR: return X86EMUL_OKAY;  /* write is silently discarded */
> 
> 2. There are too many handlers. Example for RDMSR:
>         priv_op_read_msr()
>         hvm_msr_read_intercept()
>         vmce_rdmsr()
>         svm_msr_read_intercept()
>         vmx_msr_read_intercept()
>         nvmx_msr_read_intercept()
>         rdmsr_viridian_regs()
>         ...
> 
> This series tries to address the above issues in the following way.
> 2 types of MSR policy objects are introduced:
> 
>     1. Per-Domain policy (struct msr_domain_policy) -- for shared MSRs
>     2. Per-vCPU policy (struct msr_vcpu_policy) -- for unique MSRs
> 
> Each domain and each vCPU inside a domain will now have an associated
> MSR policy object. Contents of these structures are defined during
> domain creation. For now, it's just a copy of either HVM_MAX or PV_MAX
> policy, depending on a guest's type. But in the future it should be
> possible to control the availability and values in guest's MSRs from
> a toolstack. However, any MSR manipulations must be done together with
> CPUID ones.
> 
> Once policy objects are in place, it becomes easy to introduce unified
> guest's RDMSR and WRMSR handlers. They work directly with MSR policy
> objects since all the state of guest's MSRs is contained there.
> 
> Main idea of having MSR policy is to define a set and contents of MSRs
> that a guest sees. All other MSRs should be inaccessible (access would
> generate a GP fault). And this MSR information should also be sent in
> the migration stream.
> 
> Since it's impossible to convert all MSRs to use the new infrastructure
> right away, this series starts with 2 MSRs responsible for CPUID
> faulting:
> 
>     1. MSR_INTEL_PLATFORM_INFO
>     2. MSR_INTEL_MISC_FEATURES_ENABLES
> 
> My previous VMX MSR policy patch set will be rebased on top of this
> generic MSR infrastructure after it's merged.
> 
> Sergey Dyasli (5):
>   x86/msr: introduce struct msr_domain_policy
>   x86/msr: introduce struct msr_vcpu_policy
>   x86: replace arch_vcpu::cpuid_faulting with msr_vcpu_policy
>   x86/msr: introduce guest_rdmsr()
>   x86/msr: introduce guest_wrmsr()
> 
>  xen/arch/x86/Makefile          |   1 +
>  xen/arch/x86/cpu/intel.c       |   3 +-
>  xen/arch/x86/domain.c          |  24 ++++-
>  xen/arch/x86/hvm/hvm.c         |  18 +++-
>  xen/arch/x86/hvm/vmx/vmx.c     |  31 -------
>  xen/arch/x86/msr.c             | 203 
> +++++++++++++++++++++++++++++++++++++++++
>  xen/arch/x86/pv/emul-inv-op.c  |   4 +-
>  xen/arch/x86/pv/emul-priv-op.c |  43 ++-------
>  xen/arch/x86/setup.c           |   1 +
>  xen/include/asm-x86/domain.h   |   8 +-
>  xen/include/asm-x86/msr.h      |  33 +++++++
>  11 files changed, 292 insertions(+), 77 deletions(-)
>  create mode 100644 xen/arch/x86/msr.c
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel