[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU System and User targets

From: Kenneth Adam Miller
Subject: Re: QEMU System and User targets
Date: Thu, 15 Jul 2021 11:25:09 -0500

Well certainly, I know they are different executables. I'm just trying to understand how the different targets work.

By subsumes, I mean that just looking at the meson.build for i386, you can see that there are files added to the i386_ss, but not visibly added to the softmmu target. But the softmmu target has those files built whenever you configure and build it.

And right that's what I thought. What I'm thinking is that the i386_ss is compiled with a different implementation for those call backs based on the target and the user emulation.

On Thu, Jul 15, 2021 at 11:17 AM Peter Maydell <peter.maydell@linaro.org> wrote:
On Thu, 15 Jul 2021 at 16:59, Kenneth Adam Miller
<kennethadammiller@gmail.com> wrote:
> If I am right, the softmmu/system build target for each architecture subsumes the source of the user target.

I'm not sure what you mean by "subsumes" here. Some code in
QEMU is compiled into both the system and usermode emulators
(eg most of the CPU emulation code). Some is system mode only
(eg the device models). Some is usermode only (eg the emulation
of various system calls).

> What I was wondering is, if the user layer of qemu is used by the
> user target, and by user layer I mean the using contents of linux-user,
> then how does the system target receive the user programs instead
> of the qemu user emulation layer even within a guest that is an
> entire OS?

qemu-i386 and qemu-system-i386 are different executables.
They're built differently, and what happens when a usermode
program running inside a Linux guest inside qemu-system-i386
executes a syscall instruction is completely different from
what happens when a program running on qemu-i386 executes that
instruction. Specifically, there are different versions of the
x86_cpu_do_interrupt() function: the one for system emulation does
"update the guest CPU state in the way that the real CPU does when
an int 0x80 is executed", and the one for usermode emulation does
"raise a fake exception that will cause execution to return from
the call to cpu_exec() in linux-user/i386/cpu_loop.c:cpu_loop()
so it can emulate a syscall".

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]