Re: [RFC PATCH V1 01/12] hvm/ioreq: Make x86's IOREQ feature common

[Julien Grall <julien@xxxxxxx>]

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