From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: Kevin Tian <kevin.tian@intel.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
"jbeulich@suse.com" <jbeulich@suse.com>,
Sergey Dyasli <sergey.dyasli@citrix.com>
Subject: Re: [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr()
Date: Wed, 22 Feb 2017 08:37:49 +0000 [thread overview]
Message-ID: <1487752669.4239.1.camel@citrix.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190C40BC0@SHSMSX101.ccr.corp.intel.com>
On Tue, 2017-02-21 at 09:29 +0000, Tian, Kevin wrote:
> > From: Sergey Dyasli [mailto:sergey.dyasli@citrix.com]
> > Sent: Friday, February 17, 2017 11:43 PM
> >
> > Modify vmx_add_msr() to use a variation of insertion sort algorithm:
> > find a place for the new entry and shift all subsequent elements before
> > insertion.
> >
> > The new vmx_find_msr() exploits the fact that MSR list is now sorted
> > and reuses the existing code for binary search.
> >
> > Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
> > ---
> > v1 --> v2:
> > - qsort (heap sort) is replaced with a variant of insertion sort
> > - both host and guest MSR lists are now kept sorted
> > - vmx_find_guest_msr() is replaced with more generic vmx_find_msr()
> >
> > xen/arch/x86/hvm/vmx/vmcs.c | 45
> > ++++++++++++++++++++++++++++++++++++--
> > xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
> > 2 files changed, 44 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> > index 454d444..49587d6 100644
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -1307,6 +1307,44 @@ static int construct_vmcs(struct vcpu *v)
> > return 0;
> > }
> >
> > +static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
>
> what is 'elt' short for?
The prototype was taken directly from bsearch():
int (*cmp)(const void *key, const void *elt)
I believe that elt stands for element.
>
> > +{
> > + const u32 *msr = key;
> > + const struct vmx_msr_entry *entry = elt;
> > +
> > + if ( *msr > entry->index )
> > + return 1;
> > + if ( *msr < entry->index )
> > + return -1;
> > +
> > + return 0;
> > +}
> > +
> > +struct vmx_msr_entry *vmx_find_msr(u32 msr, int type)
> > +{
> > + struct vcpu *curr = current;
> > + unsigned int msr_count;
> > + struct vmx_msr_entry *msr_area;
> > +
> > + if ( type == VMX_GUEST_MSR )
> > + {
> > + msr_count = curr->arch.hvm_vmx.msr_count;
> > + msr_area = curr->arch.hvm_vmx.msr_area;
> > + }
> > + else
> > + {
> > + ASSERT(type == VMX_HOST_MSR);
> > + msr_count = curr->arch.hvm_vmx.host_msr_count;
> > + msr_area = curr->arch.hvm_vmx.host_msr_area;
> > + }
> > +
> > + if ( msr_area == NULL )
> > + return NULL;
> > +
> > + return bsearch(&msr, msr_area, msr_count, sizeof(struct vmx_msr_entry),
> > + vmx_msr_entry_key_cmp);
> > +}
> > +
> > int vmx_read_guest_msr(u32 msr, u64 *val)
> > {
> > struct vcpu *curr = current;
> > @@ -1375,14 +1413,17 @@ int vmx_add_msr(u32 msr, int type)
> > __vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
> > }
> >
> > - for ( idx = 0; idx < *msr_count; idx++ )
> > + for ( idx = 0; (*msr_area)[idx].index <= msr && idx < *msr_count; idx++ )
>
> risk of out-of-boundary access.
How exactly out-of-bounds access is possible? The original condition
idx < *msr_count
Is still being checked on each loop iteration.
>
> > if ( (*msr_area)[idx].index == msr )
> > return 0;
> >
> > if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
> > return -ENOSPC;
> >
> > - msr_area_elem = *msr_area + *msr_count;
> > + memmove(*msr_area + idx + 1, *msr_area + idx,
> > + sizeof(*msr_area_elem) * (*msr_count - idx));
> > +
> > + msr_area_elem = *msr_area + idx;
> > msr_area_elem->index = msr;
> > msr_area_elem->mbz = 0;
> >
> > diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > index c30aab6..903af51 100644
> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > @@ -529,6 +529,7 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int
> > type);
> > void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
> > int vmx_read_guest_msr(u32 msr, u64 *val);
> > int vmx_write_guest_msr(u32 msr, u64 val);
> > +struct vmx_msr_entry *vmx_find_msr(u32 msr, int type);
> > int vmx_add_msr(u32 msr, int type);
> > void vmx_vmcs_switch(paddr_t from, paddr_t to);
> > void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
> > --
> > 2.9.3
>
>
--
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-22 8:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 15:42 [PATCH v2 0/3] x86/vmx: fix for vmentry failure with TSX bits in LBR Sergey Dyasli
2017-02-17 15:42 ` [PATCH v2 1/3] x86/vmx: introduce vmx_find_msr() Sergey Dyasli
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D190C40BC0@SHSMSX101.ccr.corp.intel.com>
2017-02-22 8:37 ` Sergey Dyasli [this message]
2017-02-22 8:40 ` Tian, Kevin
2017-02-22 8:45 ` Sergey Dyasli
2017-02-22 10:14 ` Jan Beulich
2017-02-17 15:42 ` [PATCH v2 2/3] x86/vmx: optimize vmx_read/write_guest_msr() Sergey Dyasli
2017-02-21 9:31 ` Tian, Kevin
2017-02-22 10:16 ` Jan Beulich
2017-02-17 15:42 ` [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR Sergey Dyasli
2017-02-21 9:13 ` Tian, Kevin
2017-02-21 11:25 ` Andrew Cooper
2017-02-22 2:56 ` Tian, Kevin
2017-02-22 10:26 ` Jan Beulich
2017-02-22 13:58 ` Sergey Dyasli
2017-02-22 14:04 ` Andrew Cooper
2017-02-22 14:13 ` 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=1487752669.4239.1.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.