[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 08/12/2014 12:00 PM, Jan Beulich wrote:
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?

It won't. Which is why I made changes to vmx_msr_read/write_intercept() to only call this routine when we know that a VPMU register is possibly accessed.

I thought about tri-stating vpmu_do_msr() returns (-1 for faults, 0 for no registers have been accessed, 1 for successful accesses) but decided against it.

-boris


_______________________________________________
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®.