> On 29 Oct 2024, at 09:41, Jan Beulich <jbeul...@suse.com> wrote: > > On 29.10.2024 10:30, Luca Fancellu wrote: >> Hi Jan, >> >>> On 29 Oct 2024, at 08:08, Jan Beulich <jbeul...@suse.com> wrote: >>> >>> On 28.10.2024 18:38, Ayan Kumar Halder wrote: >>>> On 28/10/2024 15:01, Jan Beulich wrote: >>>>> On 28.10.2024 15:39, Ayan Kumar Halder wrote: >>>>>> On 28/10/2024 12:55, Jan Beulich wrote: >>>>>>> On 28.10.2024 13:45, Ayan Kumar Halder wrote: >>>>>>>> --- a/xen/arch/Kconfig >>>>>>>> +++ b/xen/arch/Kconfig >>>>>>>> @@ -6,11 +6,13 @@ config PHYS_ADDR_T_32 >>>>>>>> >>>>>>>> config NR_CPUS >>>>>>>> int "Maximum number of CPUs" >>>>>>>> + range 1 1 if ARM && MPU >>>>>>>> range 1 16383 >>>>>>>> default "256" if X86 >>>>>>>> default "8" if ARM && RCAR3 >>>>>>>> default "4" if ARM && QEMU >>>>>>>> default "4" if ARM && MPSOC >>>>>>>> + default "1" if ARM && MPU >>>>>>>> default "128" if ARM >>>>>>>> help >>>>>>>> Controls the build-time size of various arrays and bitmaps >>>>>>> I'm afraid I can't easily tell whether MPU can be used together with >>>>>>> any of >>>>>>> RCAR3, QEMU, or MPSOC. If it can, the new default line would need to >>>>>>> move >>>>>>> up, as it's the first one that has a match on its condition which is >>>>>>> being >>>>>>> used. >>>>>> MPU cannot be used with any of the existing platforms. >>>>> That is - qemu can't emulate such an environment, i.e. even QEMU and MPU >>>>> don't go together? >>>> >>>> Qemu has support for Aarch32 MPU at EL2 and EL1 (ie R52). As far as I am >>>> aware, there is no support for Aarch64 MPU in Qemu (ie R82). >>>> >>>> Even for R52, I could not get the upstream Qemu working (emulating some >>>> Arm reference platform). >>>> >>>> I could get the Xilinx fork of Qemu (https://github.com/Xilinx/qemu) >>>> working which emulates AMD's SoC using R52. >>>> >>>> However, this should not impact the current patch. There is no Qemu in >>>> xen/arch/arm/platforms/*. >>> >>> Aiui that's not relevant. There is a QEMU item in >>> xen/arch/arm/platforms/Kconfig. >>> I continue to fail to see why that couldn't be selected together with MPU. >>> Yet if >>> it can be, you'd end up with a default of 4, not 1, if it actually _is_ >>> selected. >>> Alternatively QEMU (and maybe also RCAR3 and MPSOC) need to be mutually >>> exclusive >>> with MPU. Hmm, looks like that's already the case, by patch 2 suppressing >>> the >>> "Platform Support" prompt. While that looks fragile to me, I'm sorry for the >>> noise then. >> >> Are you suggesting to move "default "1" if ARM && MPU” right after “default >> "256" if X86”? > > Yes.
Makes sense! With that: Reviewed-by: Luca Fancellu <luca.fance...@arm.com> > > Jan
