On Tue, Jun 07, 2022 at 06:02:15PM +0100, Jean-Philippe Brucker wrote: > Add support for version 1 of the virtio transport to kvmtool. Based on a > RFC by Sasha Levin [1], I've been trying to complete it here and there. > It's long overdue and is quite painful to rebase, so let's get it > merged. > > Several reasons why the legacy transport needs to be replaced: > > * Only 32 feature bits are supported. Most importantly > VIRTIO_F_ACCESS_PLATFORM, which forces a Linux guest to use the DMA > API, cannot be enabled. So we can't support private guests that > decrypt or share only their DMA memory with the host. Woohoo! > * Legacy virtqueue address is a 32-bit pfn, aligned on 4kB. Since Linux > guests bypass the DMA API they can't support large GPAs. > > * New devices types (iommu, crypto, memory, etc) and new features cannot > be supported. > > * New guests won't implement the legacy transport. Existing guests will > eventually drop legacy support. > > Support for modern transport becomes the default and legacy is enabled > with --virtio-legacy. > > I only tested what I could: vsock, scsi and vhost-net are currently > broken and can be fixed later (they have issues with mem regions and > feature mask, among other things). I also haven't tested big-endian. If these are broken, then shall we default to legacy mode and have the modern transport be opt-in? Otherwise we're regressing people in a confusing way. Will
