[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/3] xen/arm: make has_vpci depend on CONFIG_HAS_VPCI


  • To: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 19 Jul 2023 09:42:13 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=urAS2YzNoRjBY+LetuLyMk9uUgsXBHqnXDX79SaomeE=; b=HHWMQ+Ncbfk5nXUJv7QeW59vYMl+gJOsJiC0rsdJrEqauGSsN5WqOw4MBfW9e2Vmv9vGD9koLJ+km0NMxcJilAPN6Ehqoy+nnk732u3WbOs5S7ubFt3sRBXECdWOz4yr3HC+jUl2AoF/eaEr7/Uh1tgrYGcmXdLAdYgUA81PpjZ/6wi1nEozaNCRFUaIqcdd//aP3EUHSfVSPhhkM5zeleNtjANPZGp4zEmmmNVB9q8/4OU1pGGDiLElkZrdt02jWLvYG4v2gA3Wlv3AfNgaGMS5zvn/8e093Xyo8+z0NBIzkI5jfMMS+KFH8qSbcARY5VN2iv2VstzYMpgnddVM+w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Agqbb5QOojnV0ChjlFOxTgaVAFPHGyToCxn1z2N12DimVDjJdgwLgJ0E3smf/wBFwLIcYALArOkEmD25axi8vVtzMggTvUZd2ifM+DFNaUr/XB7eo3rOmdT/uWO4mFLAiwmf3T/3UlkbCibLboYMlDz4Aj2TZX/GcXYx2GlL+hMj10CHUZ5+VE/IXPsEcRApmFEyt8EagTU2oyU8EPq3ItMcrtDGOhMYQ9dQNNOE7spYtYB6ezEaTVV1GUHQ+8A6d4RbE7AHiE0QqBBxIfk3NTYatM1Sr5Fgbj/4YK1zD1Tr5tw6S+aS4atkK/8SGVyOj8wz/LAZ8xfVHWsgtduwHw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Artem Mygaiev <artem_mygaiev@xxxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 19 Jul 2023 07:42:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.07.2023 19:01, Stewart Hildebrand wrote:
> On 7/7/23 02:59, Jan Beulich wrote:
>> On 07.07.2023 03:47, Stewart Hildebrand wrote:
>>> --- a/xen/arch/arm/include/asm/domain.h
>>> +++ b/xen/arch/arm/include/asm/domain.h
>>> @@ -298,8 +298,7 @@ static inline void arch_vcpu_block(struct vcpu *v) {}
>>>
>>>  #define arch_vm_assist_valid_mask(d) (1UL << 
>>> VMASST_TYPE_runstate_update_flag)
>>>
>>> -/* vPCI is not available on Arm */
>>> -#define has_vpci(d)    ({ (void)(d); false; })
>>> +#define has_vpci(d) ({ IS_ENABLED(CONFIG_HAS_VPCI) && 
>>> is_hardware_domain(d); })
>>
>> While likely not much of a problem here, I think we should strive to
>> write macros such that their arguments are evaluated exactly once in
>> all cases (for side effects to occur exactly once). When that's not
>> easily possible, so be it, but here it doesn't look problematic to
>> swap both sides of the &&.
> 
> Thanks for pointing this out. Hmm... I'm considering turning it into a static 
> inline function. This would also satisfy MISRA C:2012 Dir 4.9: "A function 
> should be used in preference to a function-like macro where they are 
> interchangeable" [1].

I don't think that'll work prior to us splitting type definitions into
separate headers. You simply cannot deref d at this point (or in fact at
any point within this header), as struct domain hasn't been defined yet.

Jan

> [1] 
> https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_09.c




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.