The source for it isn't available in order that it be compiled to the desired architecture.
What 3rd party forks take this approach? On Wed, Jan 19, 2022 at 2:06 PM Alex Bennée <alex.ben...@linaro.org> wrote: > > Kenneth Adam Miller <kennethadammil...@gmail.com> writes: > > > Hello all, > > > > I just want to pose the following problem: > > > > There is a kernel module for a non-native architecture, say, arch 1. For > performance reasons, the rest of all of the software needs to run > > natively on a different arch, arch 2. Is there any way to perhaps run > multiple QEMU instances for the different architectures in such a way > > to minimize the cross architecture performance penalty? For example, I > would like the kernel module in one (non-native) QEMU instance to > > be made available, literally equivalently, in the second (native) QEMU > instance. Would there be any API or way to map across the QEMU > > instances so that the non native arch kernel module could be mapped to > > the native QEMU instance? > > What you are describing sounds like heterogeneous system modelling which > QEMU only supports in a very limited way (all vCPUs must be the same > base architecture). You can link QEMU's together by way of shared memory > but there is no other wiring together done in that case although some > 3rd party forks take this approach. > > The kernel module sounds confusing - why would you have a kernel module > that wasn't the same architecture as the kernel you are running? > > -- > Alex Bennée >
