[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure
On Mon, Feb 26, 2018 at 05:35:15PM +0000, Andrew Cooper wrote: > Dispatch from the guest_{rd,wr}msr() functions, after confirming that the > domain is configured to use viridian. This allows for simplifiction of the > viridian helpers as they don't need to cope with the "not a viridian MSR" > case. It also means that viridian MSRs which are unimplemented, or excluded > because of features, don't fall back into default handling path. > > Rename {rd,wr}msr_viridian_regs() to guest_{rd,wr}msr_viridian() for > consistency, and because the _regs suffix isn't very appropriate. > > Update them to take a vcpu pointer rather than presuming that they act on > current, which is safe for all implemented operations. Also update them to > use X86EMUL_* return values. > > Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Just two nits. > --- > CC: Jan Beulich <JBeulich@xxxxxxxx> > CC: Jun Nakajima <jun.nakajima@xxxxxxxxx> > CC: Paul Durrant <paul.durrant@xxxxxxxxxx> > CC: Kevin Tian <kevin.tian@xxxxxxxxx> > CC: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> > CC: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> > CC: Wei Liu <wei.liu2@xxxxxxxxxx> > CC: Roger Pau Monné <roger.pau@xxxxxxxxxx> > CC: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> > --- > xen/arch/x86/hvm/svm/svm.c | 6 +---- > xen/arch/x86/hvm/viridian.c | 49 > ++++++++++++++++++-------------------- > xen/arch/x86/hvm/vmx/vmx.c | 6 +---- > xen/arch/x86/msr.c | 41 +++++++++++++++++++++++++++---- > xen/include/asm-x86/hvm/viridian.h | 11 ++------- > 5 files changed, 64 insertions(+), 49 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 8b4cefd..6d8ed5c 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1967,8 +1967,7 @@ static int svm_msr_read_intercept(unsigned int msr, > uint64_t *msr_content) > else if ( ret ) > break; > > - if ( rdmsr_viridian_regs(msr, msr_content) || > - rdmsr_hypervisor_regs(msr, msr_content) ) > + if ( rdmsr_hypervisor_regs(msr, msr_content) ) > break; > > if ( rdmsr_safe(msr, *msr_content) == 0 ) > @@ -2123,9 +2122,6 @@ static int svm_msr_write_intercept(unsigned int msr, > uint64_t msr_content) > else if ( ret ) > break; > > - if ( wrmsr_viridian_regs(msr, msr_content) ) > - break; > - > switch ( wrmsr_hypervisor_regs(msr, msr_content) ) > { > case -ERESTART: > diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c > index 70aab52..23de433 100644 > --- a/xen/arch/x86/hvm/viridian.c > +++ b/xen/arch/x86/hvm/viridian.c > @@ -554,13 +554,11 @@ static void update_reference_tsc(struct domain *d, > bool_t initialize) > put_page_and_type(page); > } > > -int wrmsr_viridian_regs(uint32_t idx, uint64_t val) > +int guest_wrmsr_viridian(struct vcpu *v, uint32_t idx, uint64_t val) Since this now returns X86EMUL_* which doesn't have negative value, should this be unsigned int? > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index 7aaa2b0..2ff9361 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -139,9 +139,11 @@ int init_vcpu_msr_policy(struct vcpu *v) > > int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val) > { > - const struct cpuid_policy *cp = v->domain->arch.cpuid; > - const struct msr_domain_policy *dp = v->domain->arch.msr; > + const struct domain *d = v->domain; > + const struct cpuid_policy *cp = d->arch.cpuid; > + const struct msr_domain_policy *dp = d->arch.msr; > const struct msr_vcpu_policy *vp = v->arch.msr; > + int ret = X86EMUL_OKAY; > > switch ( msr ) > { > @@ -173,11 +175,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, > uint64_t *val) > _MSR_MISC_FEATURES_CPUID_FAULTING; > break; > > + case 0x40000000 ... 0x400001ff: I think it would be clearer to use VIRIDIAN_MSR_MIN ... VIRIDIAN_MSR_MAX. Or else the defines should be removed because you are removing all of it's users. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |