From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH v4 26/31] xen/x86: allow HVM guests to use
 hypercalls to bring up vCPUs
Date: Wed, 12 Aug 2015 02:22:56 -0600
Message-ID: <55CB1E800200007800099F84@prv-mh.provo.novell.com>
References: <1438942688-7610-1-git-send-email-roger.pau@citrix.com>
	<1438942688-7610-27-git-send-email-roger.pau@citrix.com>
	<55C500F5.1050809@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ZPRJM-0007e7-Lr
	for xen-devel@lists.xenproject.org; Wed, 12 Aug 2015 08:23:00 +0000
In-Reply-To: <55C500F5.1050809@citrix.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: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini <stefano.stabellini@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 07.08.15 at 21:03, <andrew.cooper3@citrix.com> wrote:
> On 07/08/15 11:18, Roger Pau Monne wrote:
>> @@ -1135,6 +1136,161 @@ int arch_set_info_guest(
>>  #undef c
>>  }
>>  
>> +/* Called by VCPUOP_initialise for HVM guests. */
>> +static int arch_set_info_hvm_guest(struct vcpu *v, vcpu_hvm_context_t *ctx)
>> +{
>> +    struct segment_register seg;
>> +
>> +#define get_context_seg(ctx, seg, f)                                        \
>> +    (ctx)->mode == VCPU_HVM_MODE_16B ? (ctx)->cpu_regs.x86_16.seg##_##f :   \
>> +    (ctx)->mode == VCPU_HVM_MODE_32B ? (ctx)->cpu_regs.x86_32.seg##_##f :   \
>> +    (ctx)->cpu_regs.x86_64.seg##_##f
> 
> I would be tempted to remove _context from the name, capitalise them to
> make them stick out as macros, and turn them into function style macros
> ({ }) to avoid risk of multiple expansion.

I'm kind of confused by this reply of yours: Neither does use of
({ }) make a macro function like (afaik this is tied to the macro
having parameters), nor can I see how its use would prevent
multiple expansion (even without being certain what exactly you
consider here). In general I'm advocating for not using compiler
extensions when their use doesn't serve a clear purpose. I.e. if
the above was to be re-written as a switch() statement, then the
need for using ({ }) might indeed arise.

Jan