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

Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y


  • To: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Mon, 27 Jan 2025 18:14:06 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=cloud.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=EXis3nhLG8AF4MFQxXJYh6zaHOKEM8fpkYY5dwAURtI=; b=i/YBB5izRS98UM6hdexl1kzLIsmG7BZk8VTQ+NUhqF03FIwfn+n7Z36MTAcaOTZTGXuMZIljBE7Wd+SoUjR+xf51GF/OxnPjNFQxwHpC/t2So93lCjTi0JCqlXsieAX/4y2C4nZEOFEOponAyzd/UtlbkM+QlYOaedpo3FKUYZOpTA0dEK09xt3cJDN8WOxiJELMKQ5BFyYvtmaLiLO6UemVtwlYkl22ovAUS0Q3c0GvTCdHEIUUyW2k8GFGKN4VKgc8f1G/SHCqti/2cPeZ8sMkf0OnmuDL4f1wCrUc8xoJRf9mZMtoasDzJ18Ntqsc+V2ofNX1AouNu9fv0zfqmQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VjlTPU5Bn0thS9IcsYLUMI6Xv9a9mF6+EY0topdREtc45t4k9V5yx6J2bJGGauwrwzv/uXPvWTSx1LfPyhoXN/hlOWBhEqxnmjURXYgsm15viaEzXhQC9yo5YNVksQz1enDE81E7nHv3bdw2OqGWV/O1LEayuhd8xL5egSCaGtut8SfMdsHHOj62xkGp6AOIJv+HQq+WLJaTCXMbX3nDk8rz2w9e1WsATefc56kcDRhrRcpnv8sC2sPSLsn+miD2zPHtxw6qS0W8sfIXPWkY1cKw3sBJGP5GEWPBi8c9gMQYCvY7fb7YL3Z9GVx5nDSBBjMT5wnJhcxbWS3CqHN1Nw==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, <oleksii.kurochko@xxxxxxxxx>
  • Delivery-date: Mon, 27 Jan 2025 17:14:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 27/01/2025 18:03, Alejandro Vallejo wrote:
> 
> 
> Hi,
> 
> On Mon Jan 27, 2025 at 10:45 AM GMT, Michal Orzel wrote:
>> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
>> arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
>> arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument 
>> of type 'long unsigned int', but argument 2 has type 'long long unsigned 
>> int' [-Werror=format=]
>>   102 |     printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
>>
>> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
>> Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
>> return type. Without a cast, the expression type is unsigned long long
>> which causes the issue. Fix it.
>>
>> Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / 
>> __maddr_to_virt()")
>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
>> ---
>>  xen/arch/arm/include/asm/mm.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
>> index f91ff088f6b1..a0d8e5afe977 100644
>> --- a/xen/arch/arm/include/asm/mm.h
>> +++ b/xen/arch/arm/include/asm/mm.h
>> @@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, 
>> size_t len)
>>
>>  #define virt_to_maddr(va) ({                                        \
>>      vaddr_t va_ = (vaddr_t)(va);                                    \
>> -    (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
>> +    (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & 
>> ~PAGE_MASK)); \
>>  })
>>
>>  #ifdef CONFIG_ARM_32
> 
> Out of curiosity, why not make va_to_par() and __va_to_par() return paddr_t
> rather than uint64_t? Then this cast would be unnecessary and the expression
> end up as unsigned long.
> 
> That would also cover any other uses outside this macro.
> 
> Unless I'm missing something else...
va_to_par() returns uint64_t because PAR_EL1 on Arm64 or PAR on Arm32 system 
registers are both 64bit.
So, it would not make sense (also it would be confusing) for va_to_par() to 
return already casted value.
The function ends with _par so it should reflect the register size as the name 
suggests. Macro is there
to cast this value as it also takes into account PADDR_MASK and PAGE_MASK.

~Michal




 


Rackspace

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