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

[Oleksandr <olekstysh@xxxxxxxxx>]

On 12.08.20 11:19, Julien Grall wrote:
> Hi,
Hi Julien, Stefano


> 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...
Could we please find a common ground on whether the PIO handling needs 
to be implemented on Arm or not? At least for the current patch series.

Below my thoughts:
From one side I agree that emulator shouldn't contain any arch-specific 
code, yes it is hypervisor specific but it should be arch agnostic if 
possible. So PIO case should be handled.
From other side I tend to think that it might be possible to skip PIO 
handling for the current patch series (leave it x86 specific for now as 
we do with handle_realmode_completion()).
I think nothing will prevent us from adding PIO handling later on if 
there is a real need (use-case) for that. Please correct me if I am wrong.
I would be absolutely OK with any options.

What do you think?


--
Regards,

Oleksandr Tyshchenko