Re: [PATCH v6 05/11] xen/arm: define Xen start address for FVP BaseR platform

[Julien Grall <julien@xxxxxxx>]

Hi,

On 05/12/2022 10:17, Wei Chen wrote:
> On 2022/11/10 2:24, Julien Grall wrote:
> diff --git a/xen/arch/arm/platforms/Kconfig
> > > > b/xen/arch/arm/platforms/Kconfig
> > > > > index c93a6b2756..0904793a0b 100644
> > > > > --- a/xen/arch/arm/platforms/Kconfig
> > > > > +++ b/xen/arch/arm/platforms/Kconfig
> > > > > @@ -1,6 +1,7 @@
> > > > >    choice
> > > > >        prompt "Platform Support"
> > > > >        default ALL_PLAT
> > > > > +    default FVP_BASER if ARM_V8R
> > > > Is there any reason to create a new Kconfig rather than using MPU?
> > > Did you mean FVP_BASER? If yes, we want to give each board a MACRO
> > > to indicate its specific configurations. In current series, this MACRO
> > > only be used for board specific start address.
> > See above for this.
> If we move board specific information to tailored config file, I think
> we don't need FVP_BASER.
>
> > > If you meant Armv8R, that's because Armv8R does not equal to MPU.
> > I am not entirely sure to understand. Are you saying that an existing 
> > Xen can boot on Armv8R?
> No, I didn't mean that. I just think we can't use only one MPU or one
> ARM_V8R to cover all our changes in this series. For example, some
> changes like new system registers are brought by Armv8R not the MPU.
I understand the theory. But in practice this needs to be a balance 
between finer grain and too much Kconfig.
From this series alone, it doesn't seem to be make sense to introduce 
the two. Furthermore, I am not entirely sure you will be able to make 
the MPU work without enable the ARMv8-R Kconfig.
Cheers,

--
Julien Grall