Mattias Nissler

This issue has bitten me, here are some thoughts. For context, I've been using libvfio-user to hook up PCI device models to hardware PCIe root port implementations, basically by bridging...

Thanks @tmakatos. If anyone sees issues with approach (3) please let me know - I hope to have some cycles next week to start working on this.

> It feels like a bit of a workaround of inadequate libvfio-user design though, to be honest. It would also mean that async consumers of the API, still need to...

> It's possible the sync version could read then re-queue any intermediate messages, perhaps, but there's risks there in the cases of quiesce, migration, unmap, and so on. Plus, it's...

Ah, so we've been talking past each other, I'm not intending to send the DMA reply on the main socket. Let me recap the separate socket idea again to clarify:...

> What's the point of the vfio-user server requiring a response from the client for a DMA command? For a DMA read, it wants the data from the client. There...

I don't think there's a universal answer on how hardware behaves. At the PCIe TLP level, all packets are tagged in order to match up completions, so there aren't any...

FWIW, I have implemented a first draft of the separate socket approach here: https://github.com/mnissler-rivos/libvfio-user/compare/master...mnissler-rivos:libvfio-user:socket_dma I've tested it with qemu's vfio-server implementation, and it seems to work fine. It's still lacking...

> Looks sensible to me, though not sure I follow the distinction between DMA_ACCESS_MODE_MESSAGE and DMA_ACCESS_MODE_SOCKET, since they both use sockets. Are you treating DMA_ACCESS_MODE_MESSAGE as potentially something different, not...

Thanks @jraman567 for sharing your thoughts, and I'm happy to hear we are aligned on using a separate socket for server->client commands and their replies. @jraman567 what do you think...