[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 05/16] x86/VPMU: Handle APIC_LVTPC accesses



On 01/13/2014 08:28 AM, Jan Beulich wrote:
On 06.01.14 at 20:24, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:
Update APIC_LVTPC vector when HVM guest writes to it.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

...

+void vpmu_lvtpc_update(uint32_t val)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+    apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+}
+
  int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content)
  {
      struct vpmu_struct *vpmu = vcpu_vpmu(current);
@@ -227,19 +235,21 @@ void vpmu_initialise(struct vcpu *v)
      case X86_VENDOR_AMD:
          if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
              opt_vpmu_enabled = 0;
-        break;
+        return;
case X86_VENDOR_INTEL:
          if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
              opt_vpmu_enabled = 0;
-        break;
+        return;
default:
          printk("VPMU: Initialization failed. "
                 "Unknown CPU vendor %d\n", vendor);
          opt_vpmu_enabled = 0;
-        break;
+        return;
      }
+
+    vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
  }
So what is this good for? All code paths above use "return" now,
hence how would execution get here?

Yes, it shouldn't be here. I could move it up but since we are now updating LVTPC explicitly when a guest is writing APIC I think I can just drop it altogether.

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