From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH V7 07/12] xen: Introduce monitor_op domctl
Date: Thu, 26 Mar 2015 12:55:20 +0000
Message-ID: <55140FC8020000780006DF67@mail.emea.novell.com>
References: <1426183138-24855-1-git-send-email-tamas.lengyel@zentific.com>
	<1426183138-24855-8-git-send-email-tamas.lengyel@zentific.com>
	<5513F277020000780006DD61@mail.emea.novell.com>
	<CAErYnsgVcZw+2GxRrpFk_bHrXpmRtCQaDBWseVhfCAS_3ZbiGA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAErYnsgVcZw+2GxRrpFk_bHrXpmRtCQaDBWseVhfCAS_3ZbiGA@mail.gmail.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Tim Deegan <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Razvan Cojocaru <rcojocaru@bitdefender.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Eddie Dong <eddie.dong@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Steven Maresca <steve@zentific.com>, 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>
List-Id: xen-devel@lists.xenproject.org

>>> On 26.03.15 at 13:30, <tamas.lengyel@zentific.com> wrote:
> On Thu, Mar 26, 2015 at 11:50 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 12.03.15 at 18:58, <tamas.lengyel@zentific.com> wrote:
>>> @@ -91,41 +88,55 @@ static int hvm_event_traps(uint64_t parameters, vm_event_request_t *req)
>>>      return 1;
>>>  }
>>>
>>> -static void hvm_event_cr(uint32_t reason, unsigned long value,
>>> -                         unsigned long old, uint64_t parameters)
>>> +static inline
>>> +void hvm_event_cr(uint32_t reason, unsigned long value,
>>> +                         unsigned long old, bool_t onchangeonly, bool_t sync)
>>>  {
>>> -    vm_event_request_t req = {
>>> -        .reason = reason,
>>> -        .vcpu_id = current->vcpu_id,
>>> -        .u.mov_to_cr.new_value = value,
>>> -        .u.mov_to_cr.old_value = old
>>> -    };
>>> -
>>> -    if ( (parameters & HVMPME_onchangeonly) && (value == old) )
>>> +    if ( onchangeonly && value == old )
>>> +    {
>>>          return;
>>> -
>>> -    hvm_event_traps(parameters, &req);
>>> +    }
>>> +    else
>>> +    {
>>> +        vm_event_request_t req = {
>>> +            .reason = reason,
>>> +            .vcpu_id = current->vcpu_id,
>>> +            .u.mov_to_cr.new_value = value,
>>> +            .u.mov_to_cr.old_value = old
>>> +        };
>>> +
>>> +        hvm_event_traps(sync, &req);
>>> +    }
>>
>> ... I'd really like to see such done without "else" (which would also
>> have resulted in a smaller change).
>>
> 
> So the reason why I have it under an else clause so that the
> vm_event_request_t only gets pushed on the stack if there is a need
> for it. Otherwise it would be pushed on the stack even if the function
> returns right away which IMHO is not needed.

How much of that pushing actually happens before reaching the
early return depends entirely on the compiler. Just the other day
we had a similar discussion on another thread (I think it was with
Boris).

Jan