[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 13/20] x86/VPMU: When handling MSR accesses, leave fault injection to callers
>>> On 12.08.14 at 17:47, <boris.ostrovsky@xxxxxxxxxx> wrote: > On 08/12/2014 08:45 AM, Jan Beulich wrote: >>>>> On 08.08.14 at 18:55, <boris.ostrovsky@xxxxxxxxxx> wrote: >>> @@ -476,18 +476,17 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, >>> uint64_t msr_content) >>> { >>> case MSR_CORE_PERF_GLOBAL_OVF_CTRL: >>> core2_vpmu_cxt->global_status &= ~msr_content; >>> - return 1; >>> + return 0; >>> case MSR_CORE_PERF_GLOBAL_STATUS: >>> gdprintk(XENLOG_INFO, "Can not write readonly MSR: " >>> "MSR_PERF_GLOBAL_STATUS(0x38E)!\n"); >>> - hvm_inject_hw_exception(TRAP_gp_fault, 0); >>> return 1; >> Suspicious: Most return values get flipped, but this one (and at least >> one more below) doesn't. Any such inconsistencies that are being >> corrected (assuming this is intentional) as you go should be spelled >> out in the description. And then the question of course is whether >> it's really necessary to flip the meaning of this and some similar SVM >> function's return values anyway. > > The return value of 1 of vpmu_do_msr() will now indicate that the > routine encountered a fault as opposed to indicating whether the MSR > access was to a VPMU register. And how would it now indicate that latter fact? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |