From: Julien Grall <julien@xen.org>
To: Grygorii Strashko <grygorii_strashko@epam.com>,
"Orzel, Michal" <michal.orzel@amd.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Anthony PERARD <anthony.perard@vates.tech>,
Jan Beulich <jbeulich@suse.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [XEN][PATCH 0/8] xen/arm64: make aarch32 support optional
Date: Wed, 23 Jul 2025 13:02:27 +0100 [thread overview]
Message-ID: <71fa14e0-83d7-48ec-8bd9-258ec8f6cedf@xen.org> (raw)
In-Reply-To: <add27fd8-aaa2-453a-b502-fd505ec77f94@epam.com>
Hi,
On 23/07/2025 12:48, Grygorii Strashko wrote:
>
>
> On 23.07.25 13:54, Orzel, Michal wrote:
>>
>>
>> On 23/07/2025 10:06, Julien Grall wrote:
>>>
>>>
>>> On 23/07/2025 08:58, Grygorii Strashko wrote:
>>>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>>>
>>>> Hi,
>>>
>>> Hi Grygorii,
>>>
>>>> Now Arm64 AArch32 guest support is always enabled and built-in while
>>>> not
>>>> all Arm64 platforms supports AArch32 or this support might not be
>>>> needed.
>>>
>>> I am not entirely sure I like the proliferation of using CONFIG_* for
>>> every single feature. This makes the testing a bit more complicated.
>>>
>>> Can you clarify what the goal with this patch?
>> AArch32 is used quite rarely in embedded systems. Also, in Armv9A it
>> might only
>> be implemented at EL0 if at all. When focusing on safety
>> certification, AArch32
>> related code in Xen leaves a gap in terms of coverage that cannot
>> really be
>> justified in words. This leaves us with two options: either support it
>> (lots of
>> additional testing, requirements and documents would be needed) or
>> compile it out.
>
> FYI. bloat-o-meter report for this series with CONFIG_ARM64_AARCH32=n,
> CONFIG_EXPERT=y
Thanks for sharing the bloat-o-meter. But I don't think the result below
warrant a new config. The reason provided by Michal is a better reason
as the impact on safety certification is more significant.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2025-07-23 12:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 7:58 [XEN][PATCH 0/8] xen/arm64: make aarch32 support optional Grygorii Strashko
2025-07-23 7:58 ` [XEN][PATCH 1/8] xen/arm: split set_domain_type() between arm64/arm32 Grygorii Strashko
2025-07-23 7:58 ` [XEN][PATCH 2/8] xen/arm: move vcpu_switch_to_aarch64_mode() in arch_vcpu_create() Grygorii Strashko
2025-07-23 9:16 ` Julien Grall
2025-07-23 10:19 ` Grygorii Strashko
2025-07-23 11:09 ` Julien Grall
2025-07-24 13:54 ` Grygorii Strashko
2025-07-23 11:12 ` Andrew Cooper
2025-07-23 7:58 ` [XEN][PATCH 3/8] xen/arm: move vcpu_switch_to_aarch64_mode() in arm64 Grygorii Strashko
2025-07-23 9:22 ` Julien Grall
2025-07-23 10:45 ` Grygorii Strashko
2025-07-23 7:58 ` [XEN][PATCH 4/8] xen/arm: split is_32bit/64bit_domain() between arm64/arm32 Grygorii Strashko
2025-07-23 8:32 ` Andrew Cooper
2025-07-23 7:58 ` [XEN][PATCH 6/8] xen/arm64: constify is_32/64bit_domain() macro for CONFIG_ARM64_AARCH32=n Grygorii Strashko
2025-07-23 8:37 ` Andrew Cooper
2025-07-23 7:58 ` [XEN][PATCH 5/8] xen/arm64: make aarch32 support optional Grygorii Strashko
2025-07-23 7:58 ` [XEN][PATCH 7/8] xen/arm: regs.h split subarch definitions between arm64/arm32 Grygorii Strashko
2025-07-23 7:58 ` [XEN][PATCH 8/8] xen/arm64: constify regs_mode_is_32bit macro for CONFIG_ARM64_AARCH32=n Grygorii Strashko
2025-07-23 8:06 ` [XEN][PATCH 0/8] xen/arm64: make aarch32 support optional Julien Grall
2025-07-23 10:54 ` Orzel, Michal
2025-07-23 11:48 ` Grygorii Strashko
2025-07-23 12:02 ` Julien Grall [this message]
2025-07-23 12:12 ` Grygorii Strashko
2025-07-24 14:24 ` Grygorii Strashko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71fa14e0-83d7-48ec-8bd9-258ec8f6cedf@xen.org \
--to=julien@xen.org \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.com \
--cc=grygorii_strashko@epam.com \
--cc=jbeulich@suse.com \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.