Re: [PATCH v6 00/21] Add LoongArch linux-user emulation support

[WANG Xuerui]

Hi Song,

On 9/23/21 11:09, gaosong wrote:
> > 
> > - How would you provide the necessary firmware bits? Ideally that would 
> > be some open-source reference implementation so people would be able to 
> > collaborate on that front, and to maybe customize for specialized needs 
> > (e.g. ultra-dense cloud use cases like with Firecracker).
> > 
>
> On QEMU, we only support 64 bit, So far, we have no plan to support 32 bit.
IMO it's fine to not support 32-bit for now.
> As far as I know, LoongArch BIOS is planning to open source.
And that's exciting to hear! Really looking forward to that.
> > - How is old/new kernel ABI affecting your system-level emulation 
> > compatibility? IIUC the underlying ISA and chip behavior should be the 
> > same, only difference would be the firmware-kernel ABI, but again it 
> > should be just a matter of substituting the right image.
> >
>
> We only supoort the lastet kernel [1].
>
> [1] https://github.com/loongson/linux/tree/loongarch-next
I may formed the question ambiguously; I'm actually interested in what 
kernel flavor qemu will support emulating, not what qemu runs on. IIUC 
qemu will compile and run fine on both old-world and new-world systems. 
But anyway, we'll find out when your code is out for review.
> > - Would the resulting work support emulating both old-world and 
> > new-world systems? AFAIK those commercial distros who're VERY early 
> > adopters of LoongArch are given similarly early toolchains/kernels. They 
> > belong to the old-world as a result, and are very likely to be stuck on 
> > the old-world ABI for whole major versions before migrating, if at all 
> > possible. Closed-source/commercial software also risk being available 
> > only for the old-world, and it would be extremely important to provide 
> > some degree of interoperability so that we don't split the ecosystem.
>
> On the basis of supporting the latest kernel, we will try to be compatible with 
> the old version of LoongArch.
> But the result may be incompatible。
Thanks for the clarification. Indeed focusing on new-world should be the 
right way to go, adding old-world compatibility later if possible. I 
fear adding compatibility too early would result in a franken-port not 
serving either world well nor maintainable.