On Tue, May 20, 2025 at 07:59:13AM +0200, Cédric Le Goater wrote:
> > > Would it be complex to propose a functional test for it ?
> >
> > We have a libvfio-user we can use, but this would be a problem:
> >
> > 487 │ 2025-05-19 14:19:20,304: modprobe gpio-pci-idio-16
> > 488 │ 2025-05-19
Hello John,
Would it be complex to propose a functional test for it ?
We have a libvfio-user we can use, but this would be a problem:
487 │ 2025-05-19 14:19:20,304: modprobe gpio-pci-idio-16
488 │ 2025-05-19 14:19:20,306: modprobe: FATAL: Module gpio-pci-idio-16 not
found in director
On Mon, May 19, 2025 at 02:40:12PM +0200, Cédric Le Goater wrote:
> patches 3-5 seem be ok to merge. They are first on my vfio-next
> candidates.
>
> patches 1-2 should be reworked on top of the memory_get_xlat_addr()
> changes [1] proposed by Steven.
Now v5 is out I will rebase on top of it.
>
John,
+ Steven,
On 5/15/25 17:43, John Levon wrote:
The series contains an implement of a vfio-user client in QEMU, along with a few
more preparatory patches.
The vfio-user protocol allows for implementing (PCI) devices in another
userspace process; SPDK is one example, which includes a virtua
The series contains an implement of a vfio-user client in QEMU, along with a few
more preparatory patches.
The vfio-user protocol allows for implementing (PCI) devices in another
userspace process; SPDK is one example, which includes a virtual NVMe
implementation.
The vfio-user framework consists
