Re: MMIO/PIO dispatch file descriptors (ioregionfd) design discussion

[Elena]

On Mon, Oct 25, 2021 at 01:42:56PM +0100, Stefan Hajnoczi wrote:
> On Mon, Oct 11, 2021 at 10:34:29PM -0700, elena wrote:
> > On Wed, Nov 25, 2020 at 12:44:07PM -0800, Elena Afanasova wrote:
> > > Hello,
> > >
> > 
> > Hi
> > 
> > Sorry for top-posting, just wanted to provide a quik update.
> > We are currently working on the support for ioregionfd in Qemu and will
> > be posting the patches soon. Plus the KVM patches will be posted based
> > of the RFC v3 with some fixes if there are no objections from Elena's side
> > who originally posted KVM RFC patchset.
> 
> Hi Elena,

Hello Stefan.

> I'm curious what approach you want to propose for QEMU integration. A
> while back I thought about the QEMU API. It's possible to implement it
> along the lines of the memory_region_add_eventfd() API where each
> ioregionfd is explicitly added by device emulation code. An advantage of
> this approach is that a MemoryRegion can have multiple ioregionfds, but
> I'm not sure if that is a useful feature.
>

This is the approach that is currently in the works. Agree, I dont see
much of the application here at this point to have multiple ioregions
per MemoryRegion.
I added Memory API/eventfd approach to the vfio-user as well to try
things out.

> An alternative is to cover the entire MemoryRegion with one ioregionfd.
> That way the device emulation code can use ioregionfd without much fuss
> since there is a 1:1 mapping between MemoryRegions, which are already
> there in existing devices. There is no need to think deeply about which
> ioregionfds to create for a device.
>
> A new API called memory_region_set_aio_context(MemoryRegion *mr,
> AioContext *ctx) would cause ioregionfd (or a userspace fallback for
> non-KVM cases) to execute the MemoryRegion->read/write() accessors from
> the given AioContext. The details of ioregionfd are hidden behind the
> memory_region_set_aio_context() API, so the device emulation code
> doesn't need to know the capabilities of ioregionfd.

> 
> The second approach seems promising if we want more devices to use
> ioregionfd inside QEMU because it requires less ioregionfd-specific
> code.
> 
I like this approach as well.
As you have mentioned, the device emulation code with first approach
does have to how to handle the region accesses. The second approach will
make things more transparent. Let me see how can I modify what there is
there now and may ask further questions.

Thank you for your input Stefan.
Elena

> Stefan