All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, "Tian, Kevin" <kevin.tian@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Steven Maresca <steve@zentific.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Keir Fraser <keir@xen.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>
Subject: Re: [PATCH V5 07/12] xen: Introduce monitor_op domctl
Date: Tue, 17 Feb 2015 19:20:49 +0100	[thread overview]
Message-ID: <CAErYnsgNZEZWQm8LMWZDtaRhztBcdLVi5mRQvjb5q+LFraO1rQ@mail.gmail.com> (raw)
In-Reply-To: <54E357FE02000078000609D7@mail.emea.novell.com>

On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 13.02.15 at 17:33, <tamas.lengyel@zentific.com> wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -411,7 +411,8 @@ static int hvmemul_virtual_to_linear(
>>       * being triggered for repeated writes to a whole page.
>>       */
>>      *reps = min_t(unsigned long, *reps,
>> -                  unlikely(current->domain->arch.hvm_domain.introspection_enabled)
>> +                  unlikely(current->domain->arch
>> +                            .monitor_options.mov_to_msr.extended_capture)
>>                             ? 1 : 4096);
>
> This makes no sense (especially not to a reader in a year or two):
> There's no connection between mov-to-msr and the repeat count
> capping done here. Please wrap this in a suitably named is_...() or
> has_...() or introspection_enabled() helper, with a comment at its
> definition site making the connection explicit.

It took me a while to understand what "introspection_enabled" actually
represents and all it really does at the moment is enabling the
interception of an extended set of MSRs. If something, that is a bad
variable name. Since in this series "introspection_enabled" is
removed, here I just updated the variable to the one that holds the
same information. I don't actually know what the code here does as I
didn't touch it. If this indeed has no connection to mov-to-msr, it
should have its own option field with its own name actually describing
what it does. Maybe Razvan has some more information on what is going
on here and if another variable needs to be introduced that was just
latched onto "introspection_enabled".

>
>> @@ -79,7 +76,7 @@ static int hvm_event_traps(uint64_t parameters, vm_event_request_t *req)
>>          return rc;
>>      };
>>
>> -    if ( (parameters & HVMPME_MODE_MASK) == HVMPME_mode_sync )
>> +    if ( sync )
>
> Looks like this function parameter wants to be bool_t.
>
>> +#define DISABLE_OPTION(option)              \
>> +    do {                                    \
>> +        if ( !option->enabled )             \
>> +            return -EFAULT;                 \
>> +        domain_pause(d);                    \
>> +        option->enabled = 0;                \
>> +        domain_unpause(d);                  \
>> +    } while (0)
>> +
>> +#define ENABLE_OPTION(option)               \
>> +    do {                                    \
>> +        domain_pause(d);                    \
>> +        option->enabled = 1;                \
>> +        domain_unpause(d);                  \
>> +    } while (0)
>
> If you decide not to follow Andrew's suggestion, then at the very
> least these macros need to be properly parenthesized, have all
> their parameters made explicit, and all their arguments evaluated
> exactly once.

I'm going with Andrew's suggestions.

>
>> +int monitor_domctl(struct xen_domctl_monitor_op *domctl, struct domain *d)
>> +{
>> +    /*
>> +     * At the moment only Intel HVM domains are supported. However, event
>> +     * delivery could be extended to AMD and PV domains. See comments below.
>> +     */
>> +    if ( !is_hvm_domain(d) || !cpu_has_vmx)
>> +        return -ENOSYS;
>> +
>> +    if ( domctl->op != XEN_DOMCTL_MONITOR_OP_ENABLE &&
>> +         domctl->op != XEN_DOMCTL_MONITOR_OP_DISABLE )
>> +        return -EFAULT;
>> +
>> +    switch ( domctl->subop )
>> +    {
>> +    case XEN_DOMCTL_MONITOR_SUBOP_MOV_TO_CR0:
>> +    {
>> +        /* Note: could be supported on PV domains. */
>> +        struct mov_to_cr *options = &d->arch.monitor_options.mov_to_cr0;
>
> As three of the cases need a variable of this type, please consider
> declaring it in the scope of switch() itself.
>
>> +
>> +        if ( domctl->op == XEN_DOMCTL_MONITOR_OP_ENABLE )
>> +        {
>> +            if ( options->enabled )
>> +                return -EBUSY;
>> +
>> +            options->sync = domctl->u.mov_to_cr.sync;
>> +            options->onchangeonly = domctl->u.mov_to_cr.onchangeonly;
>> +            ENABLE_OPTION(options);
>> +        }
>> +        else
>> +        {
>> +            DISABLE_OPTION(options);
>> +        }
>
> Pointless braces.
>
>> +        break;
>> +    }
>> +
>> +    case XEN_DOMCTL_MONITOR_SUBOP_MOV_TO_CR3:
>
> Here you properly add a blank line between cases - please do so
> too further down.
>
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -621,32 +621,17 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
>>          switch( vec->op )
>>          {
>>          case XEN_VM_EVENT_MONITOR_ENABLE:
>> -        case XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION:
>> -        {
>> -            rc = -ENODEV;
>> -            if ( !p2m_vm_event_sanity_check(d) )
>> -                break;
>
> Other than the revision log says, this doesn't get moved but dropped,
> which seems wrong (or would need mentioning in the description).

The declaration of the check as a separate function is dropped. The
check itself is moved into the domctl handler.

>>              rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
>> -                                    HVM_PARAM_MONITOR_RING_PFN,
>> -                                    mem_access_notification);
>> -
>> -            if ( vec->op == XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION
>> -                 && !rc )
>> -                p2m_setup_introspection(d);
>> -
>> -        }
>> -        break;
>> +                                 HVM_PARAM_MONITOR_RING_PFN,
>> +                                 mem_access_notification);
>
> I don't see what changes for these two lines. If it's indentation, it
> should be done right when the code gets added.

Indentation can't be fixed in the code addition as it breaks git -M.
It reverts to the old format where it just removes the whole file and
adds the new one. I think its a waste to add a whole new separate
patch just to fix indentations so I just fix it here.

>> +            break;
>
> This indentation change should not be necessary - the braces you
> remove here shouldn't get added in the first place when the new
> file gets introduced. Same further down.

See my previous comment.

>
>> --- /dev/null
>> +++ b/xen/include/asm-arm/monitor.h
>> @@ -0,0 +1,13 @@
>> +#ifndef __ASM_ARM_MONITOR_H__
>> +#define __ASM_ARM_MONITOR_H__
>> +
>> +#include <xen/config.h>
>
> This is pointless and should be dropped (I seem to recall having made
> the same statement before on an earlier version - please apply such
> to all of the patches in a series).

Ack.

>
>> +#include <public/domctl.h>
>> +
>> +static inline
>> +int monitor_domctl(struct xen_domctl_monitor_op *op, struct domain *d)
>
> The includes above are insufficient for the types used, or you should
> forward declare _both_ structs and not have any includes.

Just including sched.h additionally should be enough IMHO.

>
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -241,6 +241,24 @@ struct time_scale {
>>      u32 mul_frac;
>>  };
>>
>> +/************************************************/
>> +/*            monitor event options             */
>> +/************************************************/
>> +struct mov_to_cr {
>> +    uint8_t enabled;
>> +    uint8_t sync;
>> +    uint8_t onchangeonly;
>> +};
>> +
>> +struct mov_to_msr {
>> +    uint8_t enabled;
>> +    uint8_t extended_capture;
>> +};
>> +
>> +struct debug_event {
>> +    uint8_t enabled;
>> +};
>
> These are all internal structures - is there anything wrong with using
> bitfields here?

The use if bitfields is not good performance-wise AFAIK. Would there
be any benefit that would offset that?

>
>> --- /dev/null
>> +++ b/xen/include/asm-x86/monitor.h
>> @@ -0,0 +1,30 @@
>> +/*
>> + * include/asm-x86/monitor.h
>> + *
>> + * Architecture-specific monitor_op domctl handler.
>> + *
>> + * Copyright (c) 2015 Tamas K Lengyel (tamas@tklengyel.com)
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public
>> + * License v2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public
>> + * License along with this program; if not, write to the
>> + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
>> + * Boston, MA 021110-1307, USA.
>> + */
>> +
>> +#ifndef __ASM_X86_MONITOR_H__
>> +#define __ASM_X86_MONITOR_H__
>> +
>> +#include <public/domctl.h>
>> +
>> +int monitor_domctl(struct xen_domctl_monitor_op *op, struct domain *d);
>
> Same as for the ARM variant.

Ack.

>
> Jan

Thanks,
Tamas

  reply	other threads:[~2015-02-17 18:20 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 16:33 [PATCH V5 00/12] xen: Clean-up of mem_event subsystem Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures Tamas K Lengyel
2015-02-13 17:23   ` Andrew Cooper
2015-02-13 18:03     ` Tamas K Lengyel
2015-02-13 18:09       ` Andrew Cooper
2015-02-13 18:13         ` Tamas K Lengyel
2015-02-17 11:48         ` Jan Beulich
2015-02-13 16:33 ` [PATCH V5 02/12] xen/mem_event: Cleanup mem_event ring names and domctls Tamas K Lengyel
2015-02-13 17:53   ` Andrew Cooper
2015-02-13 18:06     ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 03/12] xen/mem_paging: Convert mem_event_op to mem_paging_op Tamas K Lengyel
2015-02-13 18:17   ` Andrew Cooper
2015-02-13 18:30     ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 04/12] xen: Rename mem_event to vm_event Tamas K Lengyel
2015-02-13 18:31   ` Andrew Cooper
2015-02-13 16:33 ` [PATCH V5 05/12] tools/tests: Clean-up tools/tests/xen-access Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions Tamas K Lengyel
2015-02-13 18:41   ` Andrew Cooper
2015-02-17 11:56   ` Jan Beulich
2015-02-17 17:37     ` Tamas K Lengyel
2015-02-18  9:07       ` Jan Beulich
2015-02-18 12:09         ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 07/12] xen: Introduce monitor_op domctl Tamas K Lengyel
2015-02-13 20:09   ` Andrew Cooper
2015-02-17 14:02   ` Jan Beulich
2015-02-17 18:20     ` Tamas K Lengyel [this message]
2015-02-17 18:37       ` Andrew Cooper
2015-02-17 18:48         ` Tamas K Lengyel
2015-02-17 22:59       ` Tamas K Lengyel
2015-02-18  9:26       ` Jan Beulich
2015-02-18 12:11         ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 08/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds Tamas K Lengyel
2015-02-13 20:14   ` Andrew Cooper
2015-02-13 22:48     ` Tamas K Lengyel
2015-02-13 22:53       ` Tamas K Lengyel
2015-02-13 23:00         ` Andrew Cooper
2015-02-13 23:02           ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 09/12] xen/vm_event: Decouple vm_event and mem_access Tamas K Lengyel
2015-02-13 21:05   ` Andrew Cooper
2015-02-13 23:00     ` Tamas K Lengyel
2015-02-17 14:17   ` Jan Beulich
2015-02-17 18:30     ` Tamas K Lengyel
2015-02-17 18:34       ` Andrew Cooper
2015-02-17 18:49         ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 10/12] xen/vm_event: Relocate memop checks Tamas K Lengyel
2015-02-13 21:23   ` Andrew Cooper
2015-02-13 23:20     ` Tamas K Lengyel
2015-02-13 23:24       ` Tamas K Lengyel
2015-02-17 14:25   ` Jan Beulich
2015-02-17 18:47     ` Tamas K Lengyel
2015-02-18  9:29       ` Jan Beulich
2015-02-18 12:13         ` Tamas K Lengyel
2015-02-13 16:33 ` [PATCH V5 11/12] xen/xsm: Split vm_event_op into three separate labels Tamas K Lengyel
2015-02-13 21:25   ` Andrew Cooper
2015-02-13 16:33 ` [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl Tamas K Lengyel
2015-02-13 21:44   ` Andrew Cooper
2015-02-13 23:10     ` Tamas K Lengyel
2015-02-17 14:31   ` Jan Beulich
2015-02-17 18:32     ` Tamas K Lengyel
2015-02-18  9:31       ` Jan Beulich
2015-02-18 12:18         ` Tamas K Lengyel

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=CAErYnsgNZEZWQm8LMWZDtaRhztBcdLVi5mRQvjb5q+LFraO1rQ@mail.gmail.com \
    --to=tamas.lengyel@zentific.com \
    --cc=JBeulich@suse.com \
    --cc=andres@lagarcavilla.org \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=eddie.dong@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=rshriram@cs.ubc.ca \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=steve@zentific.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yanghy@cn.fujitsu.com \
    /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.