Kenneth Adam Miller <kennethadammil...@gmail.com> writes:
> Would it be possible somehow to save the TCG cache, as with user binaries, > but for a kernel module, before then loading that kernel > module into memory the target architecture whether in or outside of > QEMU? OK let me stop you right there - TCG generated code needs a bunch of runtime support from QEMU itself and is not designed to be run standalone. All the existing issues with binary kernel modules get multiplied once you have to account for architecture differences. Even on the same architecture you can run into problems if the modules use kernel structures that have changed between releases. Even if the kernel was compiled for the exact same kernel release you are trying to run it in changes in fields, padding and layout are going to be an issue. In short this is not the solution you are looking for. Your time would be better spent reverse engineering the proprietary module and writing a open source version of it than trying to get something like this to work. Sorry. > > On Wed, Jan 19, 2022 at 2:42 PM Kenneth Adam Miller > <kennethadammil...@gmail.com> wrote: > > 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 -- Alex Bennée
