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

Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type


  • To: "Orzel, Michal" <Michal.Orzel@xxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Tue, 6 May 2025 12:56:11 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; 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=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=; b=vULMrm51t0MMcFVo+iFs0fyVdg6/z6bExj85PuXX8BzDJ9wOnvWzZss2Xj2+tiuraXBFME8J0tv/w74erzK0FX52LTf+uYiLooS+lVx528KxsBv0rG4r+ZUb7Cv9H1V2Acwkisj6WL5Uv2OE7LvC+4sPoNYFLOteImxH6bhdouB8ZMiTjM1eNIgQIlWw0O2LYFFG1xHCgb3Q45PpZuOJ4NdNdZXjXthhbm813CtBakeVcC0SE38TCyh/QUDz9ubxUwKl9qC1W6DslrbuzPI0A9Y/USJkLwKfcwLkUibAXoL1ccb4qW2A6V7LxbbUK/StaE3Jh3KS1qZYcy0/gKCGuQ==
  • 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=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=; b=WUiThnsgLqugeXnwup33Ws9Wxf3vuyIQ4zVBptfnUyL57N8svqodcNrzDlu+6Fx5KPzte3L1rOLfCjlSpbIHZiYFwGXJ1/cCAkeHDARmCeSwaSEg6drRkuQYe7H9ity6LEFUntOrKCG56lk49vSFDqduyBhPBH53tf4DGIJnFE2WgBep5Xb2i7e3y4vAkpgv12kF1r6hJOF+9dCTDthyQGa4Ecynv4yACmUyALEi+WRqNIZllB+tbMoRoi8ahiupBEVji5V9Ecb41FdSXtGeGTZse+x3hJZa33aytZ3Pk5ho5AuXbIi/mdMPAZHAxHU2abOtgnYA/wYuQy/wke93Ig==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=yDIgTw7nsG1vleemABAJrziZmoyeSmGTBFADbhRPsiZ0++xtIKWKMHU9C/geHLvGwyorCmOPsgaZm/ZCamYsIVFcCsKrUiEQHIc+IKZ3r8H5dbvgXTvkZv4Y5RR7TDo3/0FbiEJNPFZ1Fba01JLS0go0idUinhfMoa5lfK/uxaWa7CgVCiI2CPzUerx96fyiW7+/alweU+kBxAtNGTTUFQ/aC2bP5VroNhpjTvoADsTL7HE6ud+Sbx4lovMXQ7IPsYepJw6/x6eapp52nb28qS6MZ1C5hb7ybEXtEISDZ+0/XBLCSB89OhYidxgVBH3b03yJLi7+l/e4AxCOHEEq6Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=M5wt/Shst9WqZZi9Iy1BMvwpVIfL/tZs2oqCUJcRv0y0EiBJbLITxSFRPa3a5xbYDSIqk+xfjf0OrSxyNpf6cl4425nDYTTFCz6l+VwFAL6oYwlsMkwJ7q6k0kOTzPa79X2DRDFfZG45ySGKOyr7W0xUjmT0VE+NB2Z5DWiIvD7UUkcyUoFJWtap2rLWu3uq4KThkD7/UEfzyytaDiPPCIGKqdDVe28ly+Ks4f3HwVUmiK1+ToNEKuHTvSIlHrLf43Lt9FuYF9vS2PlBb24+RVgTki1q0o3txeoUlyxGXekldL1Rax/4QWYXne+tOG1gR29x8RaUdFEr9cdx21m4Ug==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 06 May 2025 12:56:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Thread-index: AQHbuRpqbs0x64sbw06OBQfYV4WEtLPFavYAgAAvLYA=
  • Thread-topic: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type

Hi Michal,

>> 
>> +/*
>> + * Excute never.
>> + * Stage 1 EL2 translation regime.
>> + * XN[1] determines whether execution of the instruction fetched from the 
>> MPU
>> + * memory region is permitted.
>> + * Stage 2 EL1/EL0 translation regime.
>> + * XN[0] determines whether execution of the instruction fetched from the 
>> MPU
>> + * memory region is permitted.
>> + */
> Why do we need this comment? If any, why do we need EL1 description if the 
> macro
> is EL2?

Uhm yes I think I can remove altogether this comment

> 
>> +#define PRBAR_EL2_XN_ENABLED  0x2
>> +
>> #ifndef __ASSEMBLY__
>> 
>> /* Protection Region Base Address Register */
>> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
>> index 0e0a7f05ade9..7b82f10d336b 100644
>> --- a/xen/arch/arm/include/asm/mpu.h
>> +++ b/xen/arch/arm/include/asm/mpu.h
>> @@ -24,6 +24,10 @@
>> #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>> #define MAX_MPU_REGION_NR       255
>> 
>> +/* Access permission attributes. */
>> +/* Read/Write at EL2, No Access at EL1/EL0. */
>> +#define AP_RW_EL2 0x0
> This macro and the previous one are used only once (I also checked your full
> tree) and cannot be set by the caller. What's the purpose of the macros then?
> Why can't we set these values in pr_of_xenaddr() and add comment next to value
> there?

Sure, I’ll do that

> 
>> +
>> #ifndef __ASSEMBLY__
>> 
>> #ifdef CONFIG_ARM_64
>> diff --git a/xen/arch/arm/include/asm/mpu/mm.h 
>> b/xen/arch/arm/include/asm/mpu/mm.h
>> index e2235e568e81..296fe74c5d61 100644
>> --- a/xen/arch/arm/include/asm/mpu/mm.h
>> +++ b/xen/arch/arm/include/asm/mpu/mm.h
>> @@ -75,6 +75,16 @@ extern void read_protection_region(pr_t *pr_read, uint8_t 
>> sel);
>>  */
>> extern void write_protection_region(const pr_t *pr_write, uint8_t sel);
> Here and ...
> 
>> 
>> +/*
>> + * Creates a pr_t structure describing a protection region.
>> + *
>> + * @base: base address as base of the protection region.
>> + * @limit: exclusive address as limit of the protection region.
>> + * @attr: attribute index for the memory type.
>> + * @return: pr_t structure describing a protection region.
>> + */
>> +extern pr_t pr_of_xenaddr(paddr_t base, paddr_t limit, unsigned int 
>> attr_idx);
> here. Please don't use extern in prototypes. It's not needed.

I see we have a mixed usage of this in arch/arm and it’s not documented to do 
otherwise
in the code style, in this case I would prefer to be explicit unless it’s a 
strong objection on your side,
let me know.


>> 
>> +pr_t pr_of_xenaddr(paddr_t base, paddr_t limit, unsigned int attr_idx)
>> +{
>> +    prbar_t prbar;
>> +    prlar_t prlar;
>> +    pr_t region;
>> +
>> +    /* Build up value for PRBAR_EL2. */
>> +    prbar = (prbar_t) {
>> +        .reg = {
>> +            .ap = AP_RW_EL2,      /* Read/Write at EL2, no access at 
>> EL1/EL0. */
>> +            .xn = PRBAR_EL2_XN_ENABLED,   /* No need to execute outside 
>> .text */
>> +        }};
>> +
>> +    switch ( attr_idx )
>> +    {
>> +    case MT_NORMAL_NC:
>> +        /*
>> +         * ARM ARM: Overlaying the shareability attribute (DDI
>> +         * 0406C.b B3-1376 to 1377)
> It's a bit odd to provide here the manual for Armv7.
> Also, our general advice is to use the latest revision.

I suspect this was copied from mfn_to_xen_entry, I’ll try to find the latest 
reference to this.

> 
>> +         *
>> +         * A memory region with a resultant memory type attribute of normal,
>> +         * and a resultant cacheability attribute of Inner non-cacheable,
>> +         * outer non-cacheable, must have a resultant shareability attribute
>> +         * of outer shareable, otherwise shareability is UNPREDICTABLE.
>> +         *
>> +         * On ARMv8 sharability is ignored and explicitly treated as outer
>> +         * shareable for normal inner non-cacheable, outer non-cacheable.
>> +         */
>> +        prbar.reg.sh = LPAE_SH_OUTER;
>> +        break;
>> +    case MT_DEVICE_nGnRnE:
>> +    case MT_DEVICE_nGnRE:
>> +        /*
>> +         * Shareability is ignored for non-normal memory, Outer is as
>> +         * good as anything.
>> +         *
>> +         * On ARMv8 sharability is ignored and explicitly treated as outer
> Does this Armv8 comments make sense? We don't support Armv7 MPU.
> 
>> +         * shareable for any device memory type.
>> +         */
>> +        prbar.reg.sh = LPAE_SH_OUTER;
>> +        break;
>> +    default:
>> +        /* Xen mappings are SMP coherent */
>> +        prbar.reg.sh = LPAE_SH_INNER;
> AFAIR MISRA C requires every clause to be terminated with break.
> That said I don't remember if we accepted this rule...

I’ll add a break, it doesn’t hurt.

Cheers,
Luca


 


Rackspace

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