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.
Xen-devel mailing list