[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B87C835.4080409@redhat.com>
Date: Fri, 26 Feb 2010 15:10:13 +0200
From: Avi Kivity <avi@...hat.com>
To: Joerg Roedel <joerg.roedel@....com>
CC: Alexander Graf <agraf@...e.de>,
Marcelo Tosatti <mtosatti@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] KVM: SVM: Optimize nested svm msrpm merging
On 02/26/2010 03:04 PM, Joerg Roedel wrote:
>
>> 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.
>
The problem was the two lists. If you had a
static struct svm_direct_access_msrs = {
u32 index;
bool longmode_only;
} direct_access_msrs = {
...
};
You could generate
static unsigned *msrpm_offsets_longmode, *msrpm_offsets_legacy;
as well as the original bitmaps at module init, no?
--
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists