On Mon, Sep 25, 2023 at 09:40:59PM -0300, Jason Gunthorpe wrote: > 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. And to complete the picture, it is the DPU software/firmware that is resposible for maintaining this ABI in your ideal world? > > > 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 Okay the picture emerges I think. Thanks! I'll try to summarize later for everyone's benefit. -- MST
