Hi,
On 11/08/2020 23:48, Stefano Stabellini wrote:
I have the impression that we disagree in what the Device Emulator is meant to
do. IHMO, the goal of the device emulator is to emulate a device in an
arch-agnostic way.
That would be great in theory but I am not sure it is achievable: if we
use an existing emulator like QEMU, even a single device has to fit
into QEMU's view of the world, which makes assumptions about host
bridges and apertures. It is impossible today to build QEMU in an
arch-agnostic way, it has to be tied to an architecture.
AFAICT, the only reason QEMU cannot build be in an arch-agnostic way is
because of TCG. If this wasn't built then you could easily write a
machine that doesn't depend on the instruction set.
The proof is, today, we are using QEMU x86 to serve Arm64 guest.
Although this is only for PV drivers.
I realize we are not building this interface for QEMU specifically, but
even if we try to make the interface arch-agnostic, in reality the
emulators won't be arch-agnostic.
This depends on your goal. If your goal is to write a standalone
emulator for a single device, then it is entirely possible to make it
arch-agnostic.
Per above, this would even be possible if you were emulating a set of
devices.
What I want to avoid is requiring all the emulators to contain
arch-specific code just because it is easier to get QEMU working on Xen
on Arm.
If we send a port-mapped I/O request
to qemu-system-aarch64 who knows what is going to happen: it is a code
path that it is not explicitly tested.
Maybe, maybe not. To me this is mostly software issues that can easily
be mitigated if we do proper testing...
Cheers,
--
Julien Grall
