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, 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. 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. Stefan
Attachment:
signature.asc
Description: PGP signature
