[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


 


Rackspace

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