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

Re: [Xen-devel] [PATCH 4/8] x86/SVM: Add vcpu scheduling support for AVIC

On 4/13/2018 12:57 PM, Andrew Cooper wrote:
On 04/04/18 00:01, Janakarajan Natarajan wrote:
@@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned 
int index)
      return &d->avic_physical_id_table[index];
+static void avic_vcpu_load(struct vcpu *v)
+    unsigned long tmp;
+    struct arch_svm_struct *s = &v->arch.hvm_svm;
+    int h_phy_apic_id;
+    struct avic_physical_id_entry *entry = (struct avic_physical_id_entry 
+    ASSERT(!test_bit(_VPF_blocked, &v->pause_flags));
+    /*
+     * Note: APIC ID = 0xff is used for broadcast.
+     *       APIC ID > 0xff is reserved.
+     */
+    h_phy_apic_id = cpu_data[v->processor].apicid;
+    ASSERT(h_phy_apic_id < AVIC_PHY_APIC_ID_MAX);
+    tmp = read_atomic((u64*)(s->avic_last_phy_id));
+    entry->host_phy_apic_id = h_phy_apic_id;
+    entry->is_running = 1;
+    write_atomic((u64*)(s->avic_last_phy_id), tmp);
What is the purpose of s->avic_last_phy_id ?

As far as I can tell, it is always an unchanging pointer into the
physical ID table, which is only ever updated synchronously in current

If so, I don't see why it needs any of these hoops to be jumped though.

s->avic_last_phy_id is used to quickly access the entry in the table.

When the code was pushed for Linux, memory barriers were used and it was suggested that atomic operations
be used instead to ensure compiler ordering. The same is done here.


Xen-devel mailing list



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