|
[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 |