[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
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Janakarajan Natarajan <Janakarajan.Natarajan@xxxxxxx>, xen-devel@xxxxxxxxxxxxx
- From: "Natarajan, Janakarajan" <jnataraj@xxxxxxx>
- Date: Thu, 19 Apr 2018 10:54:10 -0500
- Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=amd.com;
- Cc: Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Delivery-date: Thu, 19 Apr 2018 15:54:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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
*)&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.
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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
