lkml.org 
[lkml]   [2010]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/5] KVM: SVM: Optimize nested svm msrpm merging
From
Date

On 26.02.2010, at 14:04, Joerg Roedel wrote:

> On Fri, Feb 26, 2010 at 01:28:29PM +0100, Alexander Graf wrote:
>>
>> On 26.02.2010, at 13:25, 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.
>>
>> I'm still not convinced on this way of doing things. If it's static,
>> make it static. If it's dynamic, make it dynamic. Dynamically
>> generating a static list just sounds plain wrong to me.
>
> Stop. I had a static list in the first version of the patch. This list
> was fine except the fact that a developer needs to remember to update
> this list if the list of non-intercepted msrs is expanded. The whole
> reason for a dynamically built list is to take the task of maintaining
> the list away from the developer and remove a possible source of hard to
> find bugs. This is what the current approach does.

I was more thinking of replacing the function calls with a list of MSRs. You can then take that list on module init, generate the MSR bitmap once and be good.

Later you can use the same list for the nested bitmap.

Alex

\
 
 \ /
  Last update: 2010-02-26 14:11    [W:0.063 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site