On Mon, Sep 25, 2023 at 03:44:11PM -0400, Michael S. Tsirkin wrote: > > VDPA is very different from this. You might call them both mediation, > > sure, but then you need another word to describe the additional > > changes VPDA is doing. > > Sorry about hijacking the thread a little bit, but could you > call out some of the changes that are the most problematic > for you? I don't really know these details. The operators have an existing virtio world that is ABI toward the VM for them, and they do not want *anything* to change. The VM should be unware if the virtio device is created by old hypervisor software or new DPU software. It presents exactly the same ABI. So the challenge really is to convince that VDPA delivers that, and frankly, I don't think it does. ABI toward the VM is very important here. > > In this model the DPU is an extension of the hypervisor/qemu > > environment and we shift code from x86 side to arm side to increase > > security, save power and increase total system performance. > > I think I begin to understand. On the DPU you have some virtio > devices but also some non-virtio devices. So you have to > use VFIO to talk to the DPU. Reusing VFIO to talk to virtio > devices too, simplifies things for you. Yes > If guests will see vendor-specific devices from the DPU anyway, it > will be impossible to migrate such guests away from the DPU so the > cross-vendor migration capability is less important in this > use-case. Is this a good summary? Well, sort of. As I said before, the vendor here is the cloud operator, not the DPU supplier. The guest will see an AWS virtio-net function, for example. The operator will ensure that all their different implementations of this function will interwork for migration. So within the closed world of a single operator live migration will work just fine. Since the hypervisor's controlled by the operator only migrate within the operators own environment anyhow, it is an already solved problem. Jason
