On 02/26/2010 02:25 PM, Joerg Roedel wrote:
On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
+static void add_msr_offset(u32 offset)
+{
+ u32 old;
+ int i;
+
+again:
+ for (i = 0; i< MSRPM_OFFSETS; ++i) {
+ old = msrpm_offsets[i];
+
+ if (old == offset)
+ return;
+
+ if (old != MSR_INVALID)
+ continue;
+
+ if (cmpxchg(&msrpm_offsets[i], old, offset) != old)
+ goto again;
+
+ return;
+ }
+
+ /*
+ * If this BUG triggers the msrpm_offsets table has an overflow. Just
+ * increase MSRPM_OFFSETS in this case.
+ */
+ BUG();
+}
Why all this atomic cleverness? The possible offsets are all
determined statically. Even if you do them dynamically (makes sense
when considering pmu passthrough), it's per-vcpu and therefore
single threaded (just move msrpm_offsets into vcpu context).
The msr_offset table is the same for all guests. It doesn't make sense
to keep it per vcpu because it will currently look the same for all
vcpus. For standard guests this array contains 3 entrys. It is marked
with __read_mostly for the same reason.
In that case, you can calculate it during module initialization.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
