[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1] xen/arm: AArch32-V8R: Add MPU register definitions
- To: Julien Grall <julien@xxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Mon, 28 Apr 2025 19:11:06 +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=xen.org 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=HseMuBUfqlWWSPOghP252rN34H3643z5JiS/QPYM9y4=; b=LE4l9Xt8GVU1UAoArw24M7YpxeSH9vxfJ4n5Stg6zYWDqBhDm/QsEWyo8aL09lf0WFaisN57klBIHKXj6p2KnrktzJM8eLANfbiZ8jNvigpJcaMjasbSR6P7B11HQr1I/8jNtKC40xqBSyEINp7Q6d0MAOJ1MwLBRfL3ASKIqAE3CymkR5xA3GuqeSzoG0TG7/zbU90JCDkroXf2xGBnFGV4zI8BaIzw6D8C2+g+dQxBUiKGdX4DVR+lf6vSb8h5fsBoHolDjyB1vj2N13t5BOE7eEjGdHHtQ4ZIT/THUNvNbE1dZ65FgsYzCkk+uAbei/go0cQ4DHPhkMvose/8Hg==
- 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=HseMuBUfqlWWSPOghP252rN34H3643z5JiS/QPYM9y4=; b=tnRpw0/0nMo3Rj+G2IXtLscspHiRVUthiGVVAO7kxBoVt8TzKmNL6gyuK/Zbj+nxyifk95uBeAdBuFIcOnqfZebxrm8RJ3WNSy0wJL0jQmCF8XZwQFLITtFQwkSoJ3pnsvspEWmVvJA/+kMOkGEnUqsBr4kMPr+x+fbrDxjOUdGC3BM6fuvF6cKpDmcJCQiIg5+tx44O7m6R0x4NRnuMGUWLwYwXKswVt3YeE3uYYqm+vjxeB6s9/3UyjT5QtxZqy7r4FKaQukjMqpGf6qZJXjgh9d2wvDv3dmvbnf0sMu40C4HFrDW1mR2Vugy20eXFypYyPE17jiOgJhdk9ZMK7Q==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=xcCnlJcH9gW4bzzcwRd3WJLwNHfqrSpnBUpG641UDl6UBVzCH/H3Krg3h1FFBAOgAKFyFYL4/gYsIdKASg2RVXH7B0jMEQM83Op5Nx+X1HX0d5GsTrYqQhGxHDKhes8lqIgyn9yGT4mtMUZFtlz6ER4b+lEQ7nxBurUCAJNM/9SLJgRSwE20bbam0l+YvjomXxOfEj/2MAbpi7s3J3F1dennxaK8/ndrrqtRFmeb9C3hvNprAUSj/joJc0BX2T0488xD6IbOrnSGwynKzbSSFyjt0ptyvLvGAr6E9hPwOzEak55PJCNmVXThyS0slVzP9300/Kp7OSa7AvvmeAnHrA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GcOEiWEYbPanz/6kQ7fGtzQkx8Az/awND4JhP0yMruBwSYEBmf4HQY7gYyFFqKKrCce8BEbtP2DC/iiPRuhJ4ygho39bxK6wfyqgomLY59F3u80/dhv41WKN6MKvqGYSXOYRNGG6AT5fAgo6KrDKziiF1k/Q/b8qXBHfbI7ku6wrzo7lNB9OmwjXdf7Q/myANj7HjZzApkAxKTwDhtnYI75kbiWGXh8WnQllo4NEvrSpc7BO1ZERc8k8l3npvK5+K10UeLUPkGm1Tua1EmHFz5E+aI3Z6JOscVMxWTaFtYEBaXbZKaUKxB2E9URxj5Ia6V4K0/Mm2F1vjPx5Wa2P6A==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Ayan Kumar Halder <ayankuma@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Mon, 28 Apr 2025 19:11:55 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHbr7FEzJkzCX7IxEuG28e/+R7zurOo3KoAgAt3HYCAABnBAIAFFYYA
- Thread-topic: [PATCH v1] xen/arm: AArch32-V8R: Add MPU register definitions
> On 25 Apr 2025, at 14:32, Julien Grall <julien@xxxxxxx> wrote:
>
> Hi Ayan
>
> On 25/04/2025 13:00, Ayan Kumar Halder wrote:
>>>> + unsigned int ns:1; /* Reserved 0 by hardware */
>>>> + unsigned int res0:1; /* Reserved 0 by hardware */
>> Then, we can change this on Arm32 as well.
>>>> + unsigned int limit:26; /* Limit Address */
>>>
>>> NIT: Can we align the comments?
>> Ack.
>>>
>>>> + } reg;
>>>> + uint32_t bits;
>>>> +} prlar_t;
>>>> +
>>>> +/* Protection Region */
>>>> +typedef struct {
>>>> + prbar_t prbar;
>>>> + prlar_t prlar;
>>>> + uint64_t p2m_type; /* Used to store p2m types. */
>>>> +} pr_t;
>>>
>>> This looks to be common with arm64. If so, I would prefer if the structure
>>> is in a common header.
>> No, in arm64 this is
>> typedef struct {
>> prbar_t prbar;
>> prlar_t prlar;
>> } pr_t;
>> The reason being Arm64 uses unused bits (ie 'pad') to store the type.
>
> Hmmm... They are bits from the system register (prbar), right? If so, you
> can't use them for storing the p2m_type as AFAICT they are RES0.
>
> You could possibly mask the bits before writing them.
This was the approach taken in the Arm64, I think the reason was because in
this way the overall maximum structure was less than a page
and it was easier to manage something, I’ll see if I can find what, I think it
was related to p2m...
> But then, it will become risky if the fields are defined.
>
> Also, the number of MPU regions is fairly small. So, I don't think it is
> worth it to store p2m_type.
>
> Regardless that, I think it would be better to defer the introduction of
> p2m_type until guest support is added. So it will be easier to understand how
> this is going to be used and the size (for instance, I doubt 64-bit is
> necessary...).
>
> Cheers,
>
> --
> Julien Grall
>
|
