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

From: Oleksandr <olekstysh@gmail.com>
To: Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: paul@xen.org, xen-devel@lists.xenproject.org,
	"'Oleksandr Tyshchenko'" <oleksandr_tyshchenko@epam.com>,
	"'Jan Beulich'" <jbeulich@suse.com>,
	"'Andrew Cooper'" <andrew.cooper3@citrix.com>,
	"'Wei Liu'" <wl@xen.org>,
	"'Roger Pau Monné'" <roger.pau@citrix.com>,
	"'George Dunlap'" <george.dunlap@citrix.com>,
	"'Ian Jackson'" <ian.jackson@eu.citrix.com>,
	"'Jun Nakajima'" <jun.nakajima@intel.com>,
	"'Kevin Tian'" <kevin.tian@intel.com>,
	"'Tim Deegan'" <tim@xen.org>,
	"'Julien Grall'" <julien.grall@arm.com>
Subject: Re: [RFC PATCH V1 01/12] hvm/ioreq: Make x86's IOREQ feature common
Date: Thu, 20 Aug 2020 22:14:32 +0300	[thread overview]
Message-ID: <30bf5755-8324-7612-9392-1a25a361e69f@gmail.com> (raw)
In-Reply-To: <19d27a9a-ca14-cb86-52a1-6441bd24933a@xen.org>

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