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

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Julien,

I thought I had replied to your email, but when I am checking to see if 
I have addressed all your comments, I didn't find my reply on the 
mailing list. Maybe there is something wrong with my mail system, I 
didn't find it sooner. Sorry about it. Hope my reply is not too late.

On 2022/11/10 2:24, Julien Grall wrote:
> On 09/11/2022 04:55, Wei Chen wrote:
> > Hi Julien,
> Hi Wei,
>
> > >
> > We had considered to use Kconfig to define the start addresses of v8R64
> > platforms (prompt users to input the address). But we also want to 
> > provide
> > a default start address for each platform (Discussed in [1], header for
> > default value, Kconfig option for customized address).
> Why do you want to provide a default value? And how it is guaranteed 
> that it will work for most of the users?
> > We also had thought to use Kconfig to define a default start address
> > for each platform like what we had done for early printk in RFC[2].
> > But this method has been deprecated.
> Most of the current Xen is board agnostic except the UART. We push back 
> the addition of new one because the address can be found in the firmware 
> table and I wanted to avoid increase the number of option (there are 
> dozens of platform out...).
> > So if we don’t use header files, just use the Kconfig, we can't
> > provide a default start address for platforms, and have to force users
> > to enter the start address.
> I am not sure I see the problem to force the user to enter the start 
> address. My worry with per-platform default value is we end up to force 
> each vendor to provide an header in order to boot Xen.
> I think it would be better to provide a config tailored for that 
> platform (whether it is part of Xen can be debatable). This would allow 
> a user to try a release Xen on their platform with zero changes in the 
> code.
Above comments have been answered in my reply to you and Stefano.

> > > > 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.

Cheers,
Wei Chen




> Cheers,