Re: [XEN PATCH v1 1/4] arch/riscv: initial RISC-V support to build/run minimal Xen

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

On Wed, 2022-12-28 at 19:01 +0000, Andrew Cooper wrote:
> On 28/12/2022 4:51 am, Alistair Francis wrote:
> > On Mon, Dec 26, 2022 at 9:14 PM Oleksii
> > <oleksii.kurochko@xxxxxxxxx> wrote:
> > > On Fri, 2022-12-23 at 13:50 +0000, Julien Grall wrote:
> > > > On 23/12/2022 11:16, Oleksii Kurochko wrote:
> > > > > +  . = ALIGN(PAGE_SIZE);
> > > > > +  .bss : {
> > > > > +       __bss_start = .;
> > > > > +       *(.bss .bss.*)
> > > > > +       . = ALIGN(POINTER_ALIGN);
> > > > > +       __bss_end = .;
> > > > Same as .data, I would recommend to properly populate it.
> > > Do you mean to add .bss.stack_aligned, .bss.page_aligned,
> > > .bss.percpu*?
> > > One of the reasons they were skipped is they aren't used now and
> > > one
> > > more reason if to believe xen.lds.S file from ARM
> > > .bss.percpu.read_mostly should be aligned by SMP_CACHE_BYTES
> > > which
> > > requires dummy <asm/cache.h> (or not ?) which will increase the
> > > patch
> > > with unneeded stuff for now.
> > I think we should aim to get the linker file sorted right from the
> > start. Otherwise someone is going to hit a nasty bug at some point
> > in
> > the future.
> 
> What needs to happen is actually for Xen to start using a common
> linker
> script, rather than a per-arch linker script.
> 

Do you expect to see common linker script as a part of this patch
series?

> The vast majority of the linker script is not architecture specific
> to
> begin with, and the rest is easy to parametrise.
> 

I reworked xen.lds.S file.

I took xen.lds.S from ARM as a basis and
remove all arch specific sections such as *(.proc.info), *(.ex_table),
*(.ex_table.pre), *(.altinstructions), *(.teemediator.info),
*(.adev.info), *(.dev.info), *(.arch.info), *(.bug_frames.*).

So it would be possible to use xen.lds.S as a common linker script.

> But in the short term, it's more important to get something working
> and
> properly into CI, rather than to block this change waiting for
> feature
> parity with a whole load of features not currently used.
>
> ~Andrew

~Oleksii