[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.