linux-kernel - Re: [PATCH 2/5] KVM: SVM: Optimize nested svm msrpm merging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <AEBFF8CD-15D2-4DEA-B441-94F10F6F2849@suse.de>
Date:	Fri, 26 Feb 2010 14:08:25 +0100
From:	Alexander Graf <agraf@...e.de>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	Avi Kivity <avi@...hat.com>, 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 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--
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/