[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Qemu system mode emulation for heterogeneous SOC
From: |
Ancuta, Cristian |
Subject: |
RE: Qemu system mode emulation for heterogeneous SOC |
Date: |
Wed, 15 Apr 2020 13:27:05 +0000 |
Hi, thanks for taking the time.
So just to make sure I understand the MMIO stuff correctly, there's no user
mode support because user mode applications are talking to hardware through the
OS drivers and syscalls (which would run in system mode) anyway?
Also, is there a multi core board in the source tree that I could look at to
get me started ? And if there is, when emulating multiple guest cores, do they
each get their own threads, or are they run in a round-robin fashion on the
same qemu thread?
Thanks,
Cristian
-----Original Message-----
From: Peter Maydell <address@hidden>
Sent: Wednesday, April 15, 2020 11:46 AM
To: Ancuta, Cristian <address@hidden>
Cc: address@hidden
Subject: Re: Qemu system mode emulation for heterogeneous SOC
On Tue, 14 Apr 2020 at 23:08, Ancuta, Cristian <address@hidden> wrote:
> As the subject says, I was wondering if QEMU execution model allows the full
> system emulation of a custom heterogeneous SoC architecture.
Only in the very limited sense "you can have two different CPUs which are of
the same architecture", eg an Arm M-class core and an A-class core. You can't
have two CPUs which are entirely different architectures (eg PPC and Arm). In
principle this would be nice to be able to do, but in practice QEMU's current
source tree assumes that various properties of the guest CPU are compile-time
fixed, and making those all be "this is actually a variable property that
applies only to some of the CPUs being emulated" rather than just "this is set
by a #define" would be a massive effort.
> As a related question, is MMIO supported in user mode emulation?
No. Much of the infrastructure and framework for device emulation is only in
the -softmmu binaries. The user-mode emulation stuff is intended for emulating
single Linux userspace processes, which don't have direct access to device
hardware.
thanks
-- PMM