On Thu, 2024-08-29 at 07:55 -0700, Sean Christopherson wrote: > On Thu, Aug 29, 2024, Ilias Stamatis wrote: > > On Wed, 2024-08-28 at 07:25 -0700, Sean Christopherson wrote: > > > > returns a file descriptor to the caller but does not allocate a ring > > > > buffer. Userspace can then pass this fd to mmap() to actually allocate a > > > > buffer and map it to its address space. > > > > > > > > Subsequent patches will allow userspace to: > > > > > > > > - Associate the fd with a coalescing zone when registering it so that > > > > writes to that zone are accumulated in that specific ring buffer > > > > rather than the VM-wide one. > > > > - Poll for MMIO writes using this fd. > > > > > > Why? I get the desire for a doorbell, but KVM already supports "fast" I/O for > > > doorbells. > > > > What do you refer to here? ioeventfd? > > Ya. > > > Correct me if I am wrong, but my understanding is that with an > > ioeventfd the write value is not available. And that is a problem when > > that value is a head or tail pointer. > > Ah. Can you describe (or point at) an example device? I don't read many device > specs (understatement). It would be helpful to have a concrete use case for > reviewing the design itself. Intel 82599 VF is one such example. I believe NVMe is another example. > > In a perfect world, poll() support would come from a third party file type, as > this doesn't seem _that_ unique (to KVM). But AFAICT there isn't an existing > type that is a good fit, probably because it's such a simple thing.
