xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>, xen-devel@lists.xen.org
Cc: mdontu@bitdefender.com, tim@xen.org, JBeulich@suse.com
Subject: Re: [PATCH RFC V2 3/6] xen: Force-enable relevant MSR events; optimize the number of sent MSR events
Date: Fri, 11 Jul 2014 19:29:02 +0100	[thread overview]
Message-ID: <53C02CEE.7010307@citrix.com> (raw)
In-Reply-To: <53C02B53.8020107@bitdefender.com>

On 11/07/14 19:22, Razvan Cojocaru wrote:
> On 07/11/2014 09:19 PM, Andrew Cooper wrote:
>> On 11/07/14 19:09, Razvan Cojocaru wrote:
>>> On 07/11/2014 08:03 PM, Andrew Cooper wrote:
>>>> On 11/07/14 16:43, Razvan Cojocaru wrote:
>>>>> Vmx_disable_intercept_for_msr() will now refuse to disable interception of
>>>>> MSRs needed for memory introspection. It is not possible to gate this on
>>>>> mem_access being active for the domain, since by the time mem_access does
>>>>> become active the interception for the interesting MSRs has already been
>>>>> disabled (vmx_disable_intercept_for_msr() runs very early on).
>>>>>
>>>>> Changes since V1:
>>>>>  - Replaced printk() with gdprintk(XENLOG_DEBUG, ...).
>>>>>
>>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>> ---
>>>>>  xen/arch/x86/hvm/vmx/vmcs.c |   18 ++++++++++++++++++
>>>>>  1 file changed, 18 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>>>>> index 8ffc562..35fcfcc 100644
>>>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>>>> @@ -700,6 +700,24 @@ void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
>>>>>      if ( msr_bitmap == NULL )
>>>>>          return;
>>>>>  
>>>>> +    /* Filter out MSR-s needed for memory introspection */
>>>>> +    switch ( msr )
>>>> This absolutely must be gated on mem_events being enabled for the domain.
>>>>
>>>> It is too much of a performance penalty to apply to domains which are
>>>> not being introspected.
>>> I understand, but it really runs very early on, and the mem_event part
>>> comes in after the MSR interception is disabled. This effectively
>>> renders a lot of memory introspection functionality useless.
>> In which case the hypercall which enables mem_event needs to prod the
>> vmcs state an explicitly enable intercepts for these MSRs. (and
>> conversly re-disables intercepts if mem_events are disabled)
>>
>> You can probably get away with hvm_funcs to enable and disable mem events.
> That makes sense. Would Aravindh's solution also be acceptable to you
> (using a Xen command line parameter and gate it based on that rather
> than a mem_event listener being present)?
>
>
> Thanks,
> Razvan Cojocaru

Its not a question of acceptable to me.  I am not a maintainer or
committer.  I am merely offering an opinion as a member of the Xen
community.

The people you ultimately need to convince are the Intel VT-x
maintainers (who I notice are still missed off the CC list - please use
/scripts/get_maintainers.pl to identify all the people you need to CC
based on code areas your patches touch) and the general x86 maintainers.

In this case, it would be better to dynamically change the interceptions
based on the use of mem_event, rather than having someone wanting to use
mem_events have to apply the same performance penalty to all their other
VMs if they want it to actually work.

~Andrew

  reply	other threads:[~2014-07-11 18:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11 15:43 [PATCH RFC V2 1/6] xen: Emulate with no writes Razvan Cojocaru
2014-07-11 15:43 ` [PATCH RFC V2 2/6] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-07-11 16:54   ` Andrew Cooper
2014-07-11 16:57     ` Andrew Cooper
2014-07-11 18:03     ` Razvan Cojocaru
2014-07-11 18:09       ` Andrew Cooper
2014-07-11 15:43 ` [PATCH RFC V2 3/6] xen: Force-enable relevant MSR events; optimize the number of sent MSR events Razvan Cojocaru
2014-07-11 17:03   ` Andrew Cooper
2014-07-11 18:09     ` Razvan Cojocaru
     [not found]       ` <CAGU+ausrcu=L7Kf30gZJXRnnxrKe7EMYXTGByOY4agwoK0nXeA@mail.gmail.com>
2014-07-11 18:18         ` Aravindh Puthiyaparambil (aravindp)
2014-07-11 18:19       ` Andrew Cooper
2014-07-11 18:22         ` Razvan Cojocaru
2014-07-11 18:29           ` Andrew Cooper [this message]
2014-07-11 15:43 ` [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events Razvan Cojocaru
2014-07-11 17:23   ` Andrew Cooper
2014-07-11 18:15     ` Razvan Cojocaru
2015-03-17 13:50     ` Razvan Cojocaru
2015-03-17 13:58       ` Jan Beulich
2015-03-17 14:07         ` Razvan Cojocaru
2015-03-17 14:20           ` Jan Beulich
2015-03-17 14:33             ` Razvan Cojocaru
2014-07-11 15:43 ` [PATCH RFC V2 5/6] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-07-11 18:06   ` Andrew Cooper
2014-07-17 11:53     ` Ian Campbell
2014-07-17 12:07       ` Razvan Cojocaru
2014-07-17 12:22     ` Razvan Cojocaru
2014-07-17 12:38       ` Andrew Cooper
2014-07-11 15:43 ` [PATCH RFC V2 6/6] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-07-11 18:36   ` Andrew Cooper
2014-07-11 18:41     ` Razvan Cojocaru
2014-07-11 19:12       ` Andrew Cooper
2014-07-11 16:23 ` [PATCH RFC V2 1/6] xen: Emulate with no writes Andrew Cooper
2014-07-11 18:00   ` Razvan Cojocaru
2014-07-14  8:37   ` Razvan Cojocaru

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=53C02CEE.7010307@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=mdontu@bitdefender.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=tim@xen.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).