On Thu, Sep 21, 2023 at 04:53:45PM -0300, Jason Gunthorpe wrote: > On Thu, Sep 21, 2023 at 03:34:03PM -0400, Michael S. Tsirkin wrote: > > > that's easy/practical. If instead VDPA gives the same speed with just > > shadow vq then keeping this hack in vfio seems like less of a problem. > > Finally if VDPA is faster then maybe you will reconsider using it ;) > > It is not all about the speed. > > VDPA presents another large and complex software stack in the > hypervisor that can be eliminated by simply using VFIO. If all you want is passing through your card to guest then yes this can be addressed "by simply using VFIO". And let me give you a simple example just from this patchset: it assumes guest uses MSIX and just breaks if it doesn't. As VDPA emulates it can emulate INT#x for guest while doing MSI on the host side. Yea modern guests use MSIX but this is about legacy yes? > VFIO is > already required for other scenarios. Required ... by some people? Most VMs I run don't use anything outside of virtio. > This is about reducing complexity, reducing attack surface and > increasing maintainability of the hypervisor environment. > > Jason Generally you get better security if you don't let guests poke at hardware when they don't have to. But sure, matter of preference - use VFIO, it's great. I am worried about the specific patchset though. It seems to deal with emulating virtio which seems more like a vdpa thing. If you start adding virtio emulation to vfio then won't you just end up with another vdpa? And if no why not? And I don't buy the "we already invested in this vfio based solution", sorry - that's not a reason upstream has to maintain it. -- MST
