Re: [PATCH 1/2] x86/VMX: introduce vmx_find_guest_msr()

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	Sergey Dyasli <sergey.dyasli@citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 1/2] x86/VMX: introduce vmx_find_guest_msr()
Date: Tue, 31 Jan 2017 11:49:03 +0000	[thread overview]
Message-ID: <62550ab6-d493-ce8b-d759-6dc0fdb88f18@citrix.com> (raw)
In-Reply-To: <5890831A020000780013561D@prv-mh.provo.novell.com>

On 31/01/17 11:29, Jan Beulich wrote:
>>>> On 25.01.17 at 18:26, <sergey.dyasli@citrix.com> wrote:
>>>>
>> @@ -1369,6 +1410,9 @@ int vmx_add_msr(u32 msr, int type)
>>          msr_area_elem->data = 0;
>>          __vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
>>          __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
>> +
>> +        sort(*msr_area, *msr_count, sizeof(struct vmx_msr_entry),
>> +             vmx_msr_entry_cmp, vmx_msr_entry_swap);
> ... how about avoiding the sort() here altogether, by simply
> going through the list linearly (which, being O(n), is still faster
> than sort())? The more that there is a linear scan already
> anyway. At which point it may then be beneficial to also keep
> the host MSR array sorted.

The entire point of sorting this list is to trade an O(n) search for
O(log(n)) in every vmentry when fixing up the LBR MSR values.

There should be no O(n) searches across the list after this patch.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel