PHPFixing
  • Privacy Policy
  • TOS
  • Ask Question
  • Contact Us
  • Home
  • PHP
  • Programming
  • SQL Injection
  • Web3.0
Showing posts with label qemu. Show all posts
Showing posts with label qemu. Show all posts

Tuesday, October 18, 2022

[FIXED] Why can macos(x86) run docker arm container arm64v8/alpine?

 October 18, 2022     docker, emulation, linux-kernel, qemu     No comments   

Issue

I happened to find that my macos(x86) can run a docker container for an arm image arm64v8/alpine, but with the following warning:

docker run -it  arm64v8/alpine uname -a

WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64) and no specific platform was requested
Linux d5509c57dd24 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020 aarch64 Linux

And I'm pretty sure the image is not a multi-arch image (docker manifest inspect --verbose arm64v8/alpine). Why can x86 run an arm container?


Solution

You are correct, the image is not multi architecture, yet, docker can run it. Reason behind this is a kernel subsystem called binfmt_misc which allows to set the magic numbers of a binary file to specific actions for their execution. You can read more in this nice wikipedia post about it.

Docker for Mac is arriving prepared for the binfmt magic, so there is nothing to be done to enable it. It will be enabled out-of-box with the installation, all you need to do is to fetch the image and run. The details of the mechanism can be found in repository of docker-for-mac project on this link.

To explain it simply, the binary images have the magic number that allows the kernel to decide how to handle the execution. When binfmt_misc intercepts a file for which it recognizes the magic numbers it will invoke the handler that is associated with the magic numbers.

This alone is not enough to run the container. The next part of the magic is QEMU which is the emulator for various CPU architectures. The kernel (binfmt_misc) will invoke the quemy for each of the binaries that are ARM64 and will emulate the ARM64v8.

This is not limited to docker nor to the virtual machine that is running the docker on macOS. Any linux system can be configured to do this.

You can use following to install it setup Ubuntu to run the emulation.

sudo apt-get install qemu binfmt-support qemu-user-static # Install the qemu packages
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes # This step will execute the registering scripts

docker run --rm -t arm64v8/ubuntu uname -m # Testing the emulation environment

More details about the whole process of the set-up can be found in the qemu-user-static repository

OP: If you are wondering what is the usefulness of this, from my personal experiance, I am using this functionality heavily when porting applications from X86 to other architectures (mainly ARM64). This allows me to run build systems for various architectures without having a physical machine on which I can run the build.



Answered By - jordanvrtanoski
Answer Checked By - Robin (PHPFixing Admin)
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

Sunday, September 11, 2022

[FIXED] How can I use QEMU to simulate mixed platforms?

 September 11, 2022     cross-platform, qemu     No comments   

Issue

Backgournd

There is a lot of documentation about using QEMU for simulating a system of particular architecture (a "platform").
For example, x86, ARM or RISCV system.
The first step is to configure QEMU target-list, for example ./configure --target-list=riscv32-softmmu.
It's also possible to provide multiple targets in the target-list, but apparently that builds an independent simulation for each specified platform.

My goal, however, is to simulate a system with mixed targets: an x86 machine which also hosts a RISCV embedded processor over PCI.

Obviously I need to implement a QEMU PCI device which would host the RISCV device on the x86 platform, and I have a good idea how to implement a generic PCI device. However, I'm not sure about the best approach to simulate both x86 and RISCV together on the same QEMU simulation.

One approach is to run two instances of QEMU (as two separate processes) and use some sort of IPC for communicating between the x86 and the RISCV simulation.
Another possible (?) approach could be to build RISCV QEMU as a loadable library and load it from x86 QEMU.
Perhaps it's even possible to have a single QEMU application that simulates both x86 and RISCV?
Yet another approach is not to use QEMU for simulating the RISCV device. I could implement a QEMU PCI device that completely encapsulates a RISCV simulation such as tiny-emu, but I would rather use QEMU for both x86 and RISCV.

My questions are:

  • Are there some guidelines or examples for a mixed-target QEMU project?
    I've searched for examples but only found references to using QEMU as a single platform simulation, where first you choose which platform you would like to run.
  • What would be the best approach for simulating a mixed platform in QEMU? Separate QEMU processes with IPC? Or is there a way to configure QEMU in such a way that it could simulates a mixed platform?

Related

https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg01969.html


Solution

QEMU does not support running multiple target architectures in the same QEMU process. (This is something we would in theory like to be able to do, but it would require a lot of reworking of core parts of QEMU which assume that the target architecture is known at compile time. So far nobody has felt it important enough to put in the significant development effort needed.)

So if you want to do this you'll need to somehow stitch together a QEMU process for the primary architecture with some other process to do the secondary architecture (QEMU or otherwise). This has been done (for instance Xilinx have an out-of-tree QEMU-based system that does this kind of thing with multiple QEMU processes) but I'm not aware of any easy off-the-shelf frameworks or setups to do it. I suspect that figuring out how time/clocks interact between the two simulations is one of the tricky aspects.



Answered By - Peter Maydell
Answer Checked By - Clifford M. (PHPFixing Volunteer)
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

Wednesday, August 17, 2022

[FIXED] Why does popen not grab the output of qemu?

 August 17, 2022     c, output, popen, qemu, stdout     No comments   

Issue

This below code works for things like /bin/ls and other programs but not for qemu. How can i get the output stream of qemu with popen? I ran qemu-x86_64 -d cpu /bin/ls and expected to get the same output as qemu but with a "read: "before it. When i run this i just just the normal qemu output in the console.

int main()
{

        /* Call program */
        FILE* file = popen("/bin/ls", "r");
        if(file == NULL)
        {
            perror("popen");
            return 0;
        }

        /* output stream of program*/
        char *out = NULL;
        size_t outlen = 0;

        /*iterate through program output stream line by line */
        while (getline(&out, &outlen, file) >= 0) 
        {
            /* print output stream */
            printf("read: %s", out);
        }

        /* cleanup */
        pclose(file);
        free(out);
         
        return 0;
}

Solution

As @rici pointed out qemu actually does not print to stdout. Qemu prints to stderr and to redirect the output from stderr to stdout for popen to catch it i simply need to add 2>&1 behind the executed command.

So instead of running:

FILE* file = popen("qemu-x86_64 -d cpu /bin/ls", "r");

I need to run:

FILE* file = popen("qemu-x86_64 -d cpu /bin/ls 2>&1", "r");


Answered By - Sbardila
Answer Checked By - Marilyn (PHPFixing Volunteer)
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg
Older Posts Home
View mobile version

Total Pageviews

Featured Post

Why Learn PHP Programming

Why Learn PHP Programming A widely-used open source scripting language PHP is one of the most popular programming languages in the world. It...

Subscribe To

Posts
Atom
Posts
All Comments
Atom
All Comments

Copyright © PHPFixing