> > > > Eric, Alex, Thank you very much for all your answers and details. > > From your answers it sounds like I need to extended vfio's resource query > > mechanism to enable flagging > > certain resources as NO_MAP and then make VFIO in QEMU act accordingly. > > That looks like the easier part. The more complex part in my view is to > > manage the trap to vfio-platform driver and emulate the access. > > > > In any way, I will take some time to process all this into a solution and > > fill in some gaps in my knowledge. > > TBH, I don't see any need to extend VFIO based on your needs so far. > VFIO already has the ability to describe whether a region supports mmap. > If it doesn't support mmap, QEMU has no choice but to use an I/O memory > region and translate VM accesses into reads and writes. vfio-pci > already makes extensive use of this capability today. I/O port regions > don't support mmap on x86, so those regions never expose an mmap capable > flag. We also require page alignment for mmap, so regions that are not > page aligned don't expose mmap for MMIO regions. PCI config space also > does not support mmap because of the emulation and virtualization we do > in that space. So not supporting mmap is really not uncommon. You > might want to look at my slides from KVM Forum 2013 [1] which shows how > VFIO can really be thought of as a conduit for decomposing a device > through a file descriptor. QEMU then recomposes it back into a device > through the QEMU driver model. Since platform devices have no standard > like PCI to provide self discovery, there are device specific drivers on > both ends with vfio-platform. Thanks,
Ok...it looks like i need dig in some more into the code :) This is very helpful. Thanks Yehuda > > Alex > > [1] http://www.linux-kvm.org/images/e/ed/Kvm-forum-2013-VFIO-VGA.pdf