From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
Kevin Tian <kevin.tian@intel.com>,
"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 1/2] x86/VMX: introduce vmx_find_guest_msr()
Date: Wed, 1 Feb 2017 09:38:53 +0000 [thread overview]
Message-ID: <1485941933.3089.4.camel@citrix.com> (raw)
In-Reply-To: <5890948402000078001356BF@prv-mh.provo.novell.com>
On Tue, 2017-01-31 at 05:43 -0700, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 31.01.17 at 13:06, <andrew.cooper3@citrix.com> wrote:
> > On 31/01/17 11:54, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 31.01.17 at 12:49, <andrew.cooper3@citrix.com> wrote:
> > > > 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.
> > > And that's indeed not the case. But the sort() is O(n * log(n)).
> > I don't understand what point you are trying to make.
> >
> > Adding MSRs to the list (turns out we have no remove yet) is a rare
> > occurrence, and in practice, this LBR addition is the only one which
> > happens at runtime rather than domain creation.
> >
> > However, you cannot have an efficient fixup on vmenter if the list isn't
> > sorted, and it is not possible to sort a list in less than O(n * log(n))
> > in the general case.
> True, but we're adding incrementally, i.e. the list is already sorted,
> and it is already being walked linearly a few lines up from where the
> sort() invocation is being added. Hence the addition can as well be
> done without sort(), and then in O(n).
1. Guest's MSR list is not sorted currently, which can be seen from
lbr_info:
MSR_IA32_LASTINTFROMIP 0x000001dd
MSR_IA32_LASTINTTOIP 0x000001de
MSR_C2_LASTBRANCH_TOS 0x000001c9
MSR_P4_LASTBRANCH_0_FROM_LIP 0x00000680
2. In the future there might be more MSRs in the list and a sorted list
is a prerequisite for fast lookups. Time complexity of vmx_add_msr()
is irrelevant since it's a "one shot" operation.
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-01 9:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 17:26 [PATCH 0/2] x86/VMX: fix for vmentry failure with TSX bits in LBR Sergey Dyasli
2017-01-25 17:26 ` [PATCH 1/2] x86/VMX: introduce vmx_find_guest_msr() Sergey Dyasli
2017-01-31 11:29 ` Jan Beulich
2017-01-31 11:49 ` Andrew Cooper
2017-01-31 11:54 ` Jan Beulich
2017-01-31 12:06 ` Andrew Cooper
2017-01-31 12:43 ` Jan Beulich
2017-02-01 9:38 ` Sergey Dyasli [this message]
2017-02-01 10:19 ` Jan Beulich
2017-02-01 10:43 ` Sergey Dyasli
2017-02-01 10:58 ` Jan Beulich
2017-01-25 17:26 ` [PATCH 2/2] x86/VMX: fix vmentry failure with TSX bits in LBR Sergey Dyasli
2017-01-31 11:52 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1485941933.3089.4.camel@citrix.com \
--to=sergey.dyasli@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.