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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 
> *)&tmp;
> +
> +    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
context.

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

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel